Fix clearAddress leaves primary-key deduplication state - #7038
Conversation
🦋 Changeset detectedLatest commit: 3f30107 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 regression test correctly reproduces the bug, but the actual implementation fix is missing from this PR. The title and commit message say "Fix" yet only a failing test is added.
Reviewed changes
- Added a focused regression test in
packages/effect/test/cluster/MessageStorage.test.tsthat demonstratesMemoryDriver.clearAddressleaves stale entries inrequestsByPrimaryKey.
⚠️ Implementation fix is missing
The diff adds the failing test but does not modify MemoryDriver.clearAddress in packages/effect/src/unstable/cluster/MessageStorage.ts. The loop at lines 992-1005 deletes from requests, unprocessed, and journal, but never removes the matching entries from requestsByPrimaryKey, so reusing a primary key still reports Duplicate. The fix needs to remove those index entries before this PR can be considered complete.
Technical details
# Missing clearAddress fix
## Affected sites
- `packages/effect/src/unstable/cluster/MessageStorage.ts:992-1005` — `clearAddress` deletes request state but leaves `requestsByPrimaryKey` entries behind
## Required outcome
- After `clearAddress(address)` returns, saving a request with a previously used primary key for that address must return `SaveResultEncoded.Success()`
## Suggested approach
- When removing a request from `requests`, also iterate `requestsByPrimaryKey` and delete entries whose `MemoryEntry.envelope.requestId` equals the removed request's ID, or rebuild the index from the remaining requests.ℹ️ Nitpicks
- The test's inline
as anyenvelope is pragmatic for the encoded driver, but usingEnvelope.Requestconstructors or helpers would be more type-safe if available.
@v0 or keep the SHA fresh with Dependabot | Fix it ➔ | View workflow run | Using Kimi K2 (free via Pullfrog for OSS) | 𝕏
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
- Added the missing
MemoryDriver.clearAddressfix that removes stalerequestsByPrimaryKeyentries whose envelope belongs to the cleared address. - Added a focused regression test demonstrating that saving a new request with a previously used primary key returns
SuccessafterclearAddress. - Added a patch changeset for the
effectpackage.
@v0 or keep the SHA fresh with Dependabot | 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
Clearing an entity address removes its requests, journal records, and unprocessed envelopes but retains the corresponding entries in the memory driver's primary-key index. Reusing one of those keys is still reported as a duplicate of the deleted request.
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.
clearAddress leaves primary-key deduplication state
Module:
effect/unstable/cluster/MessageStorageAudit ID:
effect-87e7029d5a5c69d6Severity / confidence: high / high
What happens
Clearing an entity address removes its requests, journal records, and unprocessed envelopes but retains the corresponding entries in the memory driver's primary-key index. Reusing one of those keys is still reported as a duplicate of the deleted request.
Why it happens
saveEnveloperecords each deduplication key inrequestsByPrimaryKey. TheclearAddressloop deletes matching envelopes fromunprocessed,requests, andjournal, but never finds or removes map entries whoseMemoryEntry.envelopebelongs to the cleared address.Expected behavior
After
clearAddress(address)completes, no request state for that address may remain reachable through request-id or primary-key lookup, and saving a new request with a formerly used primary key must succeed as a new request.Relevant implementation
These links and excerpts are pinned to audit base
17f0b91a243ccfe4a38d27debdc983adf434e738.packages/effect/src/unstable/cluster/MessageStorage.ts:827-1005View problematic code at
packages/effect/src/unstable/cluster/MessageStorage.ts:827-876View exact lines on GitHub
Excerpt truncated. Open the complete packages/effect/src/unstable/cluster/MessageStorage.ts:827-1005 range.
Reproduction
pnpm test --run packages/effect/test/cluster/MessageStorageClearAddressDedup.test.tsObserved failure: Focused contract assertion failed against 17f0b91, demonstrating: clearAddress leaves primary-key deduplication state.
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/cluster/MessageStorageClearAddressDedup.test.tsAudit provenance
17f0b91a243ccfe4a38d27debdc983adf434e73817f0b91a243ccfe4a38d27debdc983adf434e738effect-87e7029d5a5c69d6Closes EFF-512