You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
slack deploy updates manifest before running deploy hook, no rollback on hook failure #301
I'm trying to set up a CI deployment pipeline for a new Python Bolt-based Slack bot. I switched the bot to local manifest mode so that I can keep the dev-only local app's manifest and production deployed app's manifest in sync with the manifest.json in my repo. I am running slack deploy from a GitHub action when changes are pushed to main with a custom deploy hook that performs AWS SSM commands to update the bot instance to the latest version of the code in main.
I noticed is that when running slack deploy, the manifest is updated to Slack's servers before the custom deploy hook runs. If the deploy hook fails, there's no rollback; the manifest remains updated while the actual deployment may not have completed. This creates a potential situation where the deployed code and the manifest become out of sync.
Version
3.10.0
OS Info
Ubuntu 24.04.3 LTS (GitHub Actions runner)
Steps to reproduce:
Configure a custom deploy hook in .slack/hooks.json that exits with a non-zero status
Run slack deploy
Observe that the manifest is updated on Slack's servers
The deploy hook fails
The manifest remains updated despite the overall deploy failing
Expected result:
The manifest update should be rolled back if the deploy hook fails, OR
The deploy hook should run before the manifest is updated, so failures don't leave a partially-deployed state, OR
Some other option that achieves atomic deployment between manifest and code.
Actual result:
The manifest is permanently updated even when the deploy hook fails, leaving the Slack app configuration out of sync with the actual deployed application.
Requirements
I've read and understood the Contributing guidelines and have done my best effort to follow them.
Its awesome to read about the CLI in you continuous deployment process 🚀 @mwbrooks and @zimeg can confirm this but I think this is the first time this comes up
This seems to be a chicken and egg situation
If the manifest is updated first and then the custom deploy hook fails then the app gets into a broken state
If the app is deployed first and the manifest is updated afterward, there is still a risk that the manifest update fails and gets the app into a broken state
Activity
WilliamBergamin commentedon Jan 12, 2026
Hi @jbradbyrd thanks for bringing this up 💯
Its awesome to read about the CLI in you continuous deployment process 🚀 @mwbrooks and @zimeg can confirm this but I think this is the first time this comes up
This seems to be a chicken and egg situation
@mwbrooks & @zimeg, not sure if introducing a rollback feature is the easiest solution 🤔 we could try to use apps.manifest.validate to help us out
jbradbyrd commentedon Jan 13, 2026
Yes, I think your proposed solution would work from my perspective. Thank you for looking into this!