[QUERY] Modal timeout - "We had some trouble connecting"

[markfoden]

I appreciate that there are several threads here about timeouts, but I'm struggling to make sense of them in my current context. Grateful for guidance...

I have a modal function that gets data from a remote CRM function, saves it in a Slack datastore then updates the modal.

This is the console output showing that the remote function ran successfully (taking about 10 seconds) and then wrote successfully to the datastore:

At this point the modal fails to update and presents a "We had some trouble connecting" message:

There are then no further error messages in the console.

If I change the remote function to return dummy data within a couple of seconds, the modal works correctly. So it looks like it's a timeout thing.

I get the same behaviour whether running locally or deployed.

Grateful for any suggestions and a pointer to the latest information on timeouts.

[zimeg]

Hey @markfoden 👋 Thanks for checking the past timeout issues and writing in on this since modals do follow slightly different timeout rules.

The ten second function duration makes me think this is caused by a callback handler (block actions or a view) and not the initial function duration itself. The most recent docs on this suggest:

... functions using a block_suggestion, block_actions, view_submission, or view_closed payload, there is a 10 second timeout.

Does this seem to match what you're finding? I'd be interested in seeing a few more timestamps in the logs and even the function handlers if something else might be causing this, but I hope this is somewhat helpful to start!

[markfoden]

@zimeg Ah,thanks very much. The time out occurs during a block_action so it looks pretty certain that's the issue. I'd designed around a 15 second time out.

I'm guessing not but is there any prospect of the 10s limit being increased?

Also the reference says...

If a function has not finished running within its respective time limit, you will see an error in your log.

But I get no error. Any ideas why that might be?

[filmaj]

But I get no error. Any ideas why that might be?

This is my experience as well with respect to the interactivity event handlers timing out (such as view or block action events). Instead, at least for view events, the modal has an error banner along its top rendered, as you pointed out. I will make sure the docs get updated on this particular point.

I'm guessing not but is there any prospect of the 10s limit being increased?

I'll raise this internally and we shall see. I am of two minds about it:

1. On the one hand, without other kinds of tools or APIs from Slack, when we build integrations that live in Slack but interact with third party services we end up being handcuffed in terms of API responsiveness while at the same time trying to live within these timeout constraints imposed by Slack. The "easiest" solution seems to be "extend the timeout!" But...
2. ... on the other hand, the reason these timeouts exist is to try to keep all integration/app experiences within Slack snappy and performant. When an end-user presses a button or submits a modal, 10 seconds can feel like an awfully long time before the app/the Slack client reacts to the interaction. It's also pretty common that end-users don't really differentiate integrations/apps living within Slack from Slack itself - so sometimes we end up seeing feedback from users attributing poor integration performance to Slack itself.

I think, ideally, there are APIs and tools available to Slack app developers the delineate UI handling from other kinds of processing. This way, UI handling APIs could have strict execution time limits on them to keep them performant. At the same time, some kind of API should exist where developers can 'offload' longer running tasks. In terms of architecture, I am thinking of things like pub/sub topics/channels and queues. When we are building Slack automation apps, we are essentially building serverless applications; these kind of apps have an inherently different architecture/design that benefits from breaking down apps into the smallest possible units of computing.

Thinking about this from your particular use case's perspective:

I have a modal function that gets data from a remote CRM function, saves it in a Slack datastore then updates the modal.

Is "updates the modal" in your case dependent upon what is retrieved from the CRM? By asking this, I am trying to tease out what is user-facing vs. what is not. If the CRM response doesn't need to be user-facing (i.e. if the only way the response is used is by storing it in a datastore), this is perhaps a case where some offloading to a worker queue could help. I wonder if there's a way to decouple the various actions done in your modal function today (retrieving data from the CRM, updating the datastore, and updating the modal UI) into more modular bits.

Of course, today Slack offers no obvious API to "offload to a worker queue." However, there are certain hacky patterns we can use today to mimic this to a degree. For example, encapsulating these kind of 'background tasks' as a workflow that only ever gets tripped by a one-time, non-recurring scheduled trigger. The key 'hack' here, though, would be to only ever create this scheduled trigger in a specific way:

• the scheduled trigger is a one-time trigger. That is, it executes only once, and never on a recurring basis.
• the scheduled trigger gets dynamically created by another function or handler within your app at runtime, and its trip-time is scheduled for "a few seconds in the future." This is essentially a way to build something like a worker function / pub/sub channel.

Happy to chat through your use case further to see what we could do to enable your use case within today's constraints on our platform.

[markfoden]

@filmaj Thanks very much for your thoughtful response.

I will make sure the docs get updated

Thanks

I am of two minds

Absolutely makes sense. My situation is that I'll need to go back to the CRM to write some async code to do what's needed faster. A good discipline, and better for users. It's just that this will take a bit of time/effort (complicated reasons) and it would be nice to have the option to put this off. The users are happy to put up with the longer wait - because the Slack app makes their lives far easier than before. For now at least!

I suspect this is asking for the moon but could the timeout be configurable?

If the CRM response doesn't need to be user-facing...

It does. The data received is a fairly sophisticated analysis of how good a fit some of our suppliers might be for a deal we may offer them. The user needs to assess this before proceeding with the modal.

Happy to chat through

Thanks again. But I think the solution here is for me to improve the code in our CRM.