Workflow runs and chats ride out brief platform blips

Workflows and chats depend on many moving parts: the sandbox that runs code, the hosted browser, our database, file storage, and the sign-ins to your connected apps. When one of them hiccupped for a second, a run could fail even though nothing was wrong with your workflow. Those outages are now waited out. When one lasts too long, the run says the platform was at fault, it doesn't count toward turning the workflow off, and you get no failure email.

How it works

• Chats and agent runs pause, then pick up where they left off. If our database or job queue drops for a moment, the run waits up to about four minutes and continues from its last saved step on the same model.
• Runs that never started go again. A sandbox that fails before your code starts is replaced, then the run is rescheduled 30 seconds, 2 minutes, and 10 minutes later, so a webhook or poll event is not lost. A scheduled filter that can't run skips that check.
• Code keeps running through a dropped connection or a server restart. A code workflow's output is kept in its sandbox, so losing our connection to it, or the server watching it, no longer fails the run: another server picks it up.
• Flaky third-party calls retry. A code workflow's read that gets a 429, a 5xx, or a dropped connection is retried up to three times.
• The hosted browser reloads its own proxy errors, when it opens and mid-session, and never reloads a submitted form.

Also shipped

• A chat pinned to a Token Tunnel model waits out a subscription cooldown for up to about two and a half minutes.
• Database, storage, and app sign-in calls retry for a few seconds.