Slack Message Indicates "Approved" Status Despite 401 Unauthorized Error

[evict]

When an unauthenticated user clicks the "Approve" button on a Slack message integration, the Slack UI updates to show the request as "Approved" even though the backend call failed with an unauthorized error. This creates a discrepancy where the UI shows a success state that does not reflect the actual state of the data.

Expected Behavior
The Slack message should remain in its original "Pending" state (or revert to it). An error message should ideally be displayed to the user (e.g., via an ephemeral message) stating that the action failed due to lack of authorization.

The Slack integration is likely using an "optimistic update" pattern. The UI should be updated to:

• Wait for a 200 OK response from the server before changing the message blocks.
• If a non-200 response is received, use respond_url to send an ephemeral message to the user explaining the failure.

[hughneale]

Hello,

@evict Correct and a known behavior. I'll better highlight this in the docs. We have an internal ticket to improve this. However, the current issue is that.

• Agents are designed to be deployed internally - which means there's no callable endpoint for slack to interact with / check the state and update the blocks to reflect the actual state of the workflow. We're building an external SaaS product that can better handle these public callbacks.
• As a design compromise for now its an optimistic update. Once a slack block has been interacted with it'll update who interacted with it and then as part of the approval notification it'll post a new slack message if additional approvals are required.
• You could further improve the readability and add an additional notification workflow block to message the users to let them know what happened with their interaction.

Hope that makes sense.

H

[evict]

Agents are designed to be deployed internally - which means there's no callable endpoint for slack to interact with / check the state and update the blocks to reflect the actual state of the workflow.

Wouldn't it be an option to use the Slack API from the agent? So we essentially handle this locally as well? We would also love to be able to approve straight from Slack, because the provided email is trusted. Opening the web page on approval / denial is adding friction and shouldn't be necessary if Slack callbacks can be self-hosted.