Resolve session-XXXXXXXX task dirs to their full-UUID metadata - #28
Open
dgruhin-hrizn wants to merge 1 commit into
Open
Resolve session-XXXXXXXX task dirs to their full-UUID metadata#28dgruhin-hrizn wants to merge 1 commit into
dgruhin-hrizn wants to merge 1 commit into
Conversation
Newer Claude Code names task directories session-XXXXXXXX using the first 8 chars of the session UUID, while the transcript is still written as <full-uuid>.jsonl. loadSessionMetadata keys off the JSONL filename and /api/sessions looks up by task-directory name, so the keys never match: name and project come back null for every such session, and the "All Projects" dropdown ends up empty because it is built from those values. Reported in L1AD#19. I could not reproduce it locally -- Claude Code 2.1.227 writes 7/7 full-UUID task dirs on this machine and zero session- ones -- so this is written to be a no-op when the triggering layout is absent, and was verified against a synthetic directory that reproduces it. Two deliberate differences from the fix suggested in the issue: Aliases live in their own cache rather than being written into the metadata map. An alias then cannot shadow a real entry, exact matches win structurally rather than by ordering, and anything that iterates the metadata map does not see phantom duplicate sessions. Aliases are only emitted for a prefix owned by exactly one session. 8 hex chars is 32 bits, so collisions are not hypothetical -- roughly 1% odds by ~9,300 sessions and ~50% by ~77,000, and heavy users do accumulate thousands of transcripts. An unconditional alias would confidently attribute a session to the wrong project. On a collision this emits nothing, degrading to exactly today's behaviour. Verified: with an unambiguous prefix, tasks/session-054ba1af resolves to the slug and cwd from 054ba1af-....jsonl. After adding a second JSONL sharing that prefix, name and project go back to null rather than picking one. Full-UUID sessions are unaffected on both synthetic and real data.
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
1 participant
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.
Fixes #19.
The bug
Newer Claude Code names task directories
session-XXXXXXXXusing the first 8 chars of the session UUID, while the transcript is still written as<full-uuid>.jsonl.loadSessionMetadatakeys off the JSONL filename and/api/sessionslooks up by task-directory name, so the keys never match —nameandprojectcome backnullfor every such session, and the "All Projects" dropdown ends up empty because it's built from exactly those values.Reproduction caveat, stated up front
I could not reproduce this locally. Claude Code 2.1.227 writes 7/7 full-UUID task dirs on this machine and zero
session-ones, so the reporter is presumably on a different build. This patch is therefore written to be a no-op when the triggering layout is absent, and was verified against a synthetic directory that reproduces it.Two deliberate differences from the fix suggested in the issue
1. Aliases live in their own cache, not written into the metadata map. An alias then cannot shadow a real entry, exact matches win structurally rather than by insertion order, and anything that iterates the metadata map doesn't see phantom duplicate sessions. (That last one matters if a second pass over
metadatais ever added — as in #29.)2. Aliases are only emitted for a prefix owned by exactly one session. 8 hex chars is 32 bits, so collisions aren't hypothetical — roughly 1% odds by ~9,300 sessions and ~50% by ~77,000, and heavy users do accumulate thousands of transcripts. An unconditional alias would confidently attribute a session to the wrong project, which is worse than showing a UUID. On a collision this emits nothing and behaviour is exactly as today.
Verification
tasks/session-054ba1af+ one054ba1af-….jsonl054ba1afprefixnull— refuses to guess