Issue with `respond` to update message returning cant_update_message about bolt-js HOT 10 OPEN

Hi @callumsteele4 ! 🤔 This cant_update_message error appears to happen when Slack thinks the app doesn't have the authentication necessary to make the update.

The steps you've highlighted in the sequence of events all look right to me. Any chance the some reason the timestamp you're passing through metadata is not the timestamp of the original message or getting mutated somehow? Other reasons why the error could be being returned:

• There's a channel permissions restriction (seems unlikely)
• The thread is locked (seems unlikely)

Do you have the ability to share a code snippet for us to try to see if we can reproduce your issue?

from bolt-js.

Hey @srajiang, thanks for the prompt reply!

I'm using the body.message.ts on a app.action call that is hit when interacting with a set of overflow actions on the original message that I want to update - is this the correct message timestamp?

The channel is private (but the app is invited), could that have an impact? Edit: this also happens in public channels.

I'm using the client passed into the app.view function from the modal to make the chat.update call, which I assume has the correct token to be used for updating the message. Is it possible that respond is creating a message that the Slack app is not authorised to modify, e.g. creating the message as the user?

I'm assuming I shouldn't be passing as_user, as when I use true for this value it has the above error and when I use false it is reported as deprecated.

I'll have a look into whether I can create a minimal reproduction of this issue over the weekend.

Thanks again for your assistance!

from bolt-js.

Simplifying things somewhat, I still see this error even directly hitting the API with the bot user oauth token:

Presumably this suggests there's either something incorrect with the scopes the app has or the message itself?

Scopes are:

      "scopes": [
        "channels:read",
        "commands",
        "groups:read",
        "users:read",
        "team:read",
        "chat:write"
      ],

If I use chat.postMessage to create a message, I can then successfully use chat.update to modify it. So perhaps the issue here is the use of respond?

from bolt-js.

I'm using the body.message.ts on a app.action call that is hit when interacting with a set of overflow actions on the original message that I want to update - is this the correct message timestamp?

Should be! Assuming this original message was sent by your app, and assuming the ts returned as a response to the chat.postMessage call your app made (respond if memory serves makes this API call under the hood, but you could rule out by making the API call directly instead of using respond and inspecting the response payload) matches the ts you're getting in the body.message.ts for the app.action.

The channel is private (but the app is invited), could that have an impact? Edit: this also happens in public channels.

Does your app's bot user token start with an xoxb (bot) or an xoxp (user)? The chat:write scope is available as both a bot and a user scope, and shouldn't matter...

I'm using the client passed into the app.view function from the modal to make the chat.update call, which I assume has the correct token to be used for updating the message.

Yes, assuming you've set up bolt the right way with the token available in the environment and the App declared to use the environment variable, you shouldn't need to explicitly pass a token.

from bolt-js.

Does your app's bot user token start with an xoxb (bot) or an xoxp (user)? The chat:write scope is available as both a bot and a user scope, and shouldn't matter...

xoxb.

Yup, I'll dig into this a little more over the weekend I think. I suspect its something up with what respond is doing given I can update a message I directly post via the API. I'll dig into the code in this repository / dependencies to see what its calling on the API as well as use postMessage directly instead of respond.

Thanks!

from bolt-js.

It does look to be an issue with using respond.

This errors when I attempt to use updateMessage on the resulting message from respond:

await respond({ ...response, response_type: "in_channel" });

This successfully updates when I use updateMessage on the resulting message from postMessage:

await client.chat.postMessage({
  channel: channelId,
  text: response.text,
  blocks: response.blocks,
  unfurl_links: false,
});

This also successfully updates when I use updateMessage on the resulting message from say:

await say({
  blocks: response.blocks,
  text: response.text,
  unfurl_links: false,
});

Perhaps there are some limitations around updating a message with a message_ts that was originally created via a response_url (as occurs with respond)? I can't find any documentation mentioning this but I can't really think of any other likely cause for this.

Given I can use chat.postMessage or say, this unblocks me, but it does feel like something that is either a bug or needs to be documented. Thoughts?

from bolt-js.

Ah @callumsteele4 - this fell off my radar for a bit, but glad you were able to get unblocked in any case.

I noticed in the docs theres a replace_original property:

Since respond() is a utility for calling the response_url, it behaves in the same way. You can pass a JSON object with a new message payload that will be published back to the source of the original interaction with optional properties like response_type (which has a value of in_channel or ephemeral), replace_original, and delete_original.

Were you using this property?

from bolt-js.

Hi @srajiang,

The message is originally posted without replace_original.

Further attempts to update the message succeed when I've directly interacted with the message, am supplying replace_original: true, and use respond. This has not been an issue I've encountered.

The above issue is with regards to updating a message when using chat.update, as I don't have this available due to attempting to update it from an interaction with a modal that was created as a result of an interaction with the message.

See the Steps to Reproduce in the original message, copied below:

The sequence of events is:

1. User invokes a slash command
2. Server acks
3. Server invokes respond with the message contents
4. User interacts with an element of the message
5. Server acks
6. Server returns a modal via views.open
7. User interacts with modal and submits
8. Server acks
9. Server attempts to update the message contents returned in (3) via chat.update

I'm passing the message timestamp through steps 4->7 via metadata in the modal, and utilising that in chat.update.

from bolt-js.

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

from bolt-js.

I still believe this requires further investigation.

from bolt-js.