[QUERY] Changes in local environment affecting deployed workflows

[mirianbatista]

Question

Hello! I built an app following this excellent README and, after completing the development, I ran a slack deploy. Recently, I needed to modify the app and, to my surprise, the changes I made appeared in the workflows whose links were created during the slack deploy. Questions:

1. Is there any configuration I missed to prevent this from happening?
2. What exactly happens when slack deploy is executed? I carefully read the documentation for slack run and slack deploy (ref, ref) as well as other documentation and issues in this repository, but it wasn’t clear if/how I can make sure that local environment code does not affect the deployed code. Can you help me with this?

Context

There was a trigger link working normally in a Slack channel, created when I ran slack deploy (I am sure of this because there was no (local) next to the trigger link/workflow name). I needed to modify the app code, so I ran a slack run and chose the local environment (to ensure I was in the local environment, I generated another trigger link to test in a test channel, and it has (local) in the name). However, these changes were affecting the workflows in the channel with deployed trigger links. Observed behaviors:

• Completed uses of workflows in the channel with deployed trigger links change from data-support-app to data-support-app (local) when I modify the workflow code, and the log App successfully reinstalled appears (I assumed this reinstalled was about the local environment).
• Running slack deploy removes the (local) from all previous uses in the channel with deployed trigger links.
• In the terminal where I chose to run slack run in the local environment, logs appear about the slack deploy I ran (with a cloud emoji):

  ☁️  2024-05-09 10:10:50 [info] Application Updated by user 'Uxxx' on team 'Txxx'
  File change detected: path/to/file.ts, reinstalling app...
  App successfully reinstalled

Environment

"deno-slack-sdk/": "https://deno.land/x/deno_slack_sdk@2.9.0/",
"deno-slack-api/": "https://deno.land/x/deno_slack_api@2.3.2/",

deno 1.42.3 (release, x86_64-unknown-linux-gnu)
v8 12.3.219.9
typescript 5.4.3

#29~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Apr 4 14:39:20 UTC 2

Requirements

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[filmaj]

Hi @mirianbatista ! Sorry about your confusing experience, let's try to get to the bottom of it.

Your understanding about the isolation of local (slack run) vs. deployed (slack deploy) apps is correct: they are two separate apps. The slack run app that you run locally has its own application ID which is different from the slack deploy app that Slack runs for you. So any triggers and code associated to each context is isolated from the other context.

Let me provide an overview of what happens when you run run vs. deploy.

slack run

1. An isolated instance of your app is either created or updated. This local version of your app should have a unique application ID (should look like A1234ABCD). This app ID should be surfaced in various places when you use the Slack CLI (like when you are selecting workspaces via the prompts). An application's configuration is almost entirely dictated by the contents of your manifest file. If you run the CLI in verbose mode (via the --verbose flag) you can see this App ID being passed to various Slack HTTP APIs. The creation/updating of an app configuration is mediated by the apps.manifest.* suite of Slack HTTP APIs.
2. The CLI's process will block your terminal as it establishes a connection with the Slack backend in order to receive events of things happening within the Slack workspace that are relevant to your app (i.e. messages being sent to channels your app is a part of, and so on).
3. As each such event is sent to your app, the CLI will pick it up and invoke the relevant deno function as applicable. For example, if your app uses a custom function as one of its steps in a workflow that is executed, the CLI will pass the relevant function-specific payload and deno run your custom function code locally.

slack deploy

1. Same thing here for slack deploy, except that the app ID here will be different than the app ID used for slack run.
2. The CLI will then bundle your code locally on your machine and zip it up. This gets sent to a Slack API responsible for managing deployed app bundles.
3. CLI process completes. At this point, as events relevant to your deployed app happen, they will get dispatched to the Slack infrastructure hosting your app bundle.

---

So, with all this said, I don't think that the following statement is possible:

Recently, I needed to modify the app and, to my surprise, the changes I made appeared in the workflows whose links were created during the slack deploy

Can you expand on "the changes you made"? What slack commands were run? What were the changes made? Did you change function code? Did you change trigger code? What was the order of operations in terms of code changes and slack CLI commands?

[mirianbatista]

@filmaj thank you so much for the detailed explanation of slack run vs slack deploy, this was essential to identify that the slack.json app_id was the same as the slack.dev.json app_id; this was the cause of all the confusion. Thanks again for the clarifications!

[filmaj]

Happy to help! Out of curiousity: how did you end up in the situation where the app ID was the same for both? That should basically never happen - want to make sure the tooling isn't somehow getting itself twisted up and causing this situation.

[mirianbatista]

@filmaj At the beginning of the development of the app that is currently working in my company's Slack, I tested the workflow codes in another personal Slack. The app is a support request app that creates support tickets for users to my team and generates a page in Notion for the user to track the progress of their request. Since I didn’t have the permission to create the page in the company’s Notion, I used a personal Slack and Notion until I got the necessary permission to use the company’s Slack and Notion. Probably, when I was removing the information from my personal Slack, I accidentally copied the content of one JSON to another. I don’t remember exactly how it happened, but I suspect that’s what occurred.

On a related note, considering that these files are crucial for the proper separation of development and production environments, do you think we could include a more detailed explanation in the deno-issue-submission documentation (ref) and/or the Team collaboration page (ref) about how each one works? Perhaps adding the valuable detailed information you provided me in this issue about how slack run and slack deploy work? I ask because I am motivated to open a PR about this, but I’m unsure if this problem happened due to my inexperience or if it’s something we can genuinely improve.

[filmaj]

Thanks a lot for the info! Super helpful as we look to improve the tooling and see what we can do to eliminate some of the sharp corners. A few follow-ups, if you don't mind?

I accidentally copied the content of one JSON to another.

Just to be clear: do you refer to the .slack/apps.*.json files (which contain app IDs that the CLI reads in order to target the appropriate app)?

do you think we could include a more detailed explanation / documentation

100% agreed, I will raise this with our api.slack.com tech writing team and we will brainstorm ways to make this clearer! I think your suggestion to clarify that in the samples' description of the .slack folder makes a lot of sense too. Will do!

Appreciate your candid feedback 🙇

[mirianbatista]

Just to be clear: do you refer to the .slack/apps.*.json files (which contain app IDs that the CLI reads in order to target the appropriate app)?

This, exactly, somehow (obviously without understanding that those files were the configurations of the dev and prod environments and without being clear about the explanation you gave here in the issue) the app_id of the file .slack/apps.json and .slack/apps.dev.json were the same

Thank you in advance for the improvements in the documentation!!

[filmaj]

For what it's worth, I have done the same thing in the past (run cp -r ./my-old-app/* ./my-new-app) and been bitten by this too, so you're not alone.