duplicate_external_id unavoidable if modal not explicitly closed

[tybro0103]

Description

Receiving duplicate_external_id error from views.open endpoint when the modal was previously open and then closed by any means other than explicitly clicking the close or submit buttons.

What type of issue is this? (place an x in one of the [ ])

• bug
• enhancement (feature request)
• question
• documentation related
• testing related
• discussion

Requirements (place an x in each of the [ ])

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.

---

Bug Report

Reproducible in:

production

Steps to reproduce:

1. Use views.open to open a modal with external_id: 'foo'.
2. Press CMD+R in Slack app to reload.
3. -the modal will now be gone-
4. Try to open the same modal with same external_id: 'foo' again.

Expected result:

The modal should open again.

Actual result:

The modal does not open, and I get the duplicate_external_id error code.

Attachments:

https://youtu.be/ITAyKDSFg0w

[swippy]

I have similar issues as mentioned above, but this is how it happened.

• Type a slack command where it triggers to show a modal (using views.open)
• Fill in some input and click the submit button where it triggers a new modal (views.open) with external_id 'foo'
• Somehow (occasionally), the next modal failed to be shown (not sure why)
• I redo above steps, from typing slack command to show the first modal
• But before I can go to the next modal, it throws duplicate_external_id error

I happened all the time. I have to modify my script to avoid of using this external_id parameter to solve the case.
I believe if there is no issue with this external_id, this external_id usage would benefit to my script without having ugly workaround solution.

Please solve this issue.

[xdesign-ricardobarata]

Just giving this one a bump! Seems like it has been opened for quite a while. In the meantime I'll have to find a work around too :D

[xdesign-ricardobarata]

For my particular use case I found that I could replace

await client.views.update({
      external_id: <external_id>
      trigger_id: body.trigger_id,
      view: <updated_view>
    });

by

await client.views.update({
      view_id: body.view.id,
      trigger_id: body.trigger_id,
      view: <updated_view>
    });

all this comes wrapped in

export const <nameoftheCallback>: Middleware<
  SlackActionMiddlewareArgs<BlockAction>
> = async ({ body, ack, client }) => {

Feels a bit slower (maybe just on my eyes), but at least is not giving me any issues