Support for RetryAfter

[eluce2]

Inngest has a concept of throwing a RetryAfterError, which is most helpful when working with external services where we hit a rate limit and I just need to retry after a specific amount of time (once the rate limit resets). Can this be added to this component?

[ianmacartney]

You can pass `runAfter` to `step.run*` - so you can return that as a status and then run it again at the right time - even better is to use the rate limiter component, so you can do a `const { retryAfter } = rateLimiter.limit(step, "mylimit", { reserve: true });` then `step.runAction(..., { runAfter })` so you run the action at exactly the right time (or immediately if the rate limit isn't hit)

…

On Wed, Sep 10, 2025 at 12:37 PM Eric Luce ***@***.***> wrote: *eluce2* created an issue (get-convex/workflow#109) <#109> Inngest has a concept of throwing a RetryAfterError, which is most helpful when working with external services where we hit a rate limit and I just need to retry after a specific amount of time (once the rate limit resets). Can this be added to this component? — Reply to this email directly, view it on GitHub <#109>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACZQW62BJEEHUGMEVHHQYT3SB4XXAVCNFSM6AAAAACGFKMYZCVHI2DSMVQWIX3LMV43ASLTON2WKOZTGQYDGNRZG43DMNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ianmacartney]

@eluce2 I think there's something here for sure - I think this could even be a Workpool primitive (rather than at the Workflow layer). One question around expectations though - should this count against the maxRetries specified for the action? Maybe that's configurable, or maybe it's tracked separately.. Maybe the easy thing is to allow it to retry ~indefinitely, since you can always change your code to stop throwing under some condition.

For mutations this would roll back the transaction, so no other writes would go through. Actions would not be able to roll back previous mutations, so would continue to need to be idempotent if they have retries.

[eluce2]

I expect it to still count towards the max retries. That's how Inngest does it. It's still a retry, just with a specified delay rather than the default exponential backoff