feat(engine): terminal status-based idempotency key release#4460
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| CREATE TYPE idempotency_method AS ENUM ('TTL', 'STATUS'); | ||
|
|
||
| ALTER TABLE "WorkflowVersion" | ||
| ADD COLUMN "idempotencyMethod" idempotency_method; |
There was a problem hiding this comment.
shouldn't we add a DEFAULT to make this easier on ourselves, so we don't need to deal with the null values?
There was a problem hiding this comment.
I don't think so, since then we'd have most rows with an idempotency method but no expression or ttl - it's probably "correct" to make the idempotency config a separate table instead and then have these all be non-null, but I don't really want to deal with adding joins all over. How strongly do you feel...?
| SELECT | ||
| UNNEST(@taskIds::BIGINT[]) AS task_id, | ||
| UNNEST(@taskInsertedAts::TIMESTAMPTZ[]) AS task_inserted_at, | ||
| UNNEST(@taskRetryCounts::INTEGER[]) AS retry_count |
There was a problem hiding this comment.
I think this might now lead to some raciness on the behavior of retry_count, though I'm not sure. I'm wondering what happens if the terminal event comes in much later, like let's say that the task retries and then a few milliseconds later the completed event is processed. Does the idempotency key get released or not? And is there ever a case where this could lead to an orphaned idempotency key?
|
|
|
|
|
|
Description
Adds a second mechanism for releasing idempotency keys, which is to release them once the task that claimed them reaches a terminal status, as requested by a few people. The implementation is pretty simple - in
releaseTaskswe just run a new query that does the cleanup, similar to how the otherrelease*queries runNeed to make sure this is okay performance-wise still and push the SDKs and docs
Type of change
Checklist
Changes have been:
🤖 AI Disclosure
Used Claude Code to replicate Python SDK changes to the other SDKs