fix: make rename replay idempotent#7
Open
Matt-Reason wants to merge 1 commit intoMartian-Engineering:masterfrom
Open
fix: make rename replay idempotent#7Matt-Reason wants to merge 1 commit intoMartian-Engineering:masterfrom
Matt-Reason wants to merge 1 commit intoMartian-Engineering:masterfrom
Conversation
When events.jsonl contains duplicate rename events (e.g. from repeated `pb update --parent=` operations on already-renamed issues), every write operation fails with "rename target matches current id" during cache rebuild. The sequence: 1. `pb update <id> --parent=<epic>` emits a rename event 2. A subsequent `pb update <id> --parent=<epic>` on the same issue emits another identical rename event 3. On cache rebuild, the first rename succeeds and adds a mapping to the renames table (old_id -> new_id) 4. The duplicate rename calls resolveIssueID(old_id) which follows the chain to new_id. Now resolvedOldID == newID, triggering the error Since events are appended to events.jsonl before RebuildCache runs, the write succeeds but the CLI exits with code 1. Every subsequent operation also fails because the stale cache triggers a rebuild that hits the same duplicate rename. The fix treats "resolvedOldID == newID" as a no-op (the rename was already applied) instead of an error, making event replay idempotent. Workaround for affected users: deduplicate rename events in events.jsonl and re-run `pb init`. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Every write operation (
create,close,update,init) fails with:Despite the error, the operation succeeds (events are appended to
events.jsonl), but the CLI exits with code 1. This breaks scripting and CI usage.Root Cause
When
events.jsonlcontains duplicate rename events,RebuildCache()fails during replay. Duplicate renames occur whenpb update --parent=is called on an issue that was already renamed to a parent-child suffix ID. The guardHasParentChildSuffixchecks the current ID, but lookup by original ID causes the check to pass and a duplicate rename event to be emitted.During cache rebuild replay:
old-id -> new-idsucceeds and adds a mapping to therenamestableold-id -> new-idcallsresolveIssueID(old-id)which follows the rename chain tonew-idresolvedOldID == newID, triggering the errorSince
AppendEvent()runs beforeRebuildCache(), the write is persisted but the exit code is 1. Every subsequent operation also fails because the stale cache triggers a rebuild that hits the same duplicate.Fix
One-line change in
applyRename(): treatresolvedOldID == newIDas a no-op (rename already applied) instead of an error. This makes event replay idempotent — the expected property of an event-sourced system.Workaround for Affected Users
Deduplicate rename events in
events.jsonland rebuild:Separate Issue: Duplicate Rename Emission
This fix makes replay tolerant of duplicates, but the root emission of duplicate renames from
pb update --parent=should also be addressed separately. When an issue has already been renamed to a parent-child ID, re-running--parent=should not emit another rename event.