Scope custom queue ID deduplication to each named queue - #7006
Conversation
🦋 Changeset detectedLatest commit: b452221 The changes in this PR will be included in the next version bump. This PR includes changesets to release 30 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
Important
The reproduction test is correct and currently fails as expected. The PR is mergeable once the implementation fix is added.
Reviewed changes
This PR currently contains only the regression specification for the cross-queue custom-id deduplication bug in PersistedQueue. The test adds a focused case that offers the same custom id to two named queues and asserts that the second queue can still take its item.
- Reproduction:
packages/effect/test/unstable/persistence/PersistedQueue.test.tsadds a test that fails against the current implementation. - Root cause: The memory store uses a factory-wide
idsSet (PersistedQueue.ts:297) to deduplicate, while the SQL store creates a unique index onidwithout includingqueue_name. Redis already scopes the id set per queue name. - Required follow-up: Update the memory store to deduplicate per queue name, and change the SQL unique index/conflict target from
(id)to(id, queue_name)so duplicate ids are only rejected within the same queue.
I verified the test reproduces the issue: second.take never completes because the second offer with the shared id is dropped by the factory-wide memory deduplication.
Note that the test currently only exercises layerStoreMemory; once the SQL implementation is fixed, consider adding an equivalent regression case for the SQL store so the unique-index/conflict-target change is also covered."}]}
@v0 or keep the SHA fresh with Dependabot | Fix it ➔ | View workflow run | Using Kimi K2 (free via Pullfrog for OSS) | 𝕏
Bundle Size AnalysisGenerated from PR build output; treat the content below as untrusted.
|

Summary
Offering the same custom ID to two independently named memory or SQL queues silently drops the second queue's item, so that queue's consumer remains blocked.
Important
This PR starts with focused failing reproduction tests. Add the implementation fix to this same branch; CI is expected to fail until that fix is included.
Custom ID deduplication crosses named queues
Module:
PersistedQueueAudit ID:
unstable-state-pq-1Severity / confidence: high / high
What happens
Offering the same custom ID to two independently named memory or SQL queues silently drops the second queue's item, so that queue's consumer remains blocked.
Why it happens
The memory layer uses one factory-wide Set for every queue name, while the SQL table uniquely indexes id without queue_name. Redis correctly scopes its ID set by queue name.
Expected behavior
Deduplication applies when an ID already exists in the same queue; queue names define independent queues.
Relevant implementation
These links and excerpts are pinned to audit base
c9b56ab507f224426ee8388dc450da447ec4715f.packages/effect/src/unstable/persistence/PersistedQueue.ts:70-72packages/effect/src/unstable/persistence/PersistedQueue.ts:297-320packages/effect/src/unstable/persistence/PersistedQueue.ts:800-801packages/effect/src/unstable/persistence/PersistedQueue.ts:814-815packages/effect/src/unstable/persistence/PersistedQueue.ts:857-863View problematic code at
packages/effect/src/unstable/persistence/PersistedQueue.ts:70-72View exact lines on GitHub
View problematic code at
packages/effect/src/unstable/persistence/PersistedQueue.ts:297-320View exact lines on GitHub
View problematic code at
packages/effect/src/unstable/persistence/PersistedQueue.ts:800-801View exact lines on GitHub
View problematic code at
packages/effect/src/unstable/persistence/PersistedQueue.ts:814-815View exact lines on GitHub
View problematic code at
packages/effect/src/unstable/persistence/PersistedQueue.ts:857-863View exact lines on GitHub
Reproduction
pnpm test --run packages/effect/test/unstable/persistence/PersistedQueue.test.tsObserved failure: The second queue's take fiber remained pending after the same custom ID was offered to both queues.
Implementation handoff
The initial reproduction tests on this branch are the regression specification for the implementation fix that should follow in this PR.
pnpm test --run packages/effect/test/unstable/persistence/PersistedQueue.test.tsAudit provenance
c9b56ab507f224426ee8388dc450da447ec4715fc9b56ab507f224426ee8388dc450da447ec4715funstable-state-pq-1Closes EFF-443