Repository navigation
Conversation
There was a problem hiding this comment.
Looks good. I reproduced the bug on dev by running serve from source against a repo whose .git/opencode is 40 NUL bytes: GET /api/location returned a 500. With this branch it returns 200 and resolves to the root commit ID. The core project tests pass, the new test fails on the base, and tsc -b for packages/core is clean.
The fix is in the right place: cached() serves both the git and Mercurial paths, and a real ID never contains control characters.
Public API is unchanged.
a60ad16 to
826e1a4
Compare
There was a problem hiding this comment.
The new push is a rebase onto the latest dev, and the change itself is unchanged. I re-checked it on the new head: a repo with a NUL-byte .git/opencode still resolves to the root commit ID through GET /api/location. The core project tests pass and tsc -b for packages/core is clean. Nothing new to raise. Public API is unchanged.
There was a problem hiding this comment.
The new commit only folds the corrupt-cache case into the existing root-commit fallback test, and the fix is unchanged. That test passes with the fix and fails without it, the core project tests pass, and tsc -b for packages/core is clean. Nothing new to raise. Public API is unchanged.
Issue for this PR
Closes #53991
Type of change
What does this PR do?
When a repo's cached project ID file (
.git/opencode) holds NUL or other control bytes, OpenCode adopts it as the project ID. Building paths from that ID then fails, so the directory can never load and the stale ID never gets repaired. A cached value with control characters is now treated as missing, so the ID is resolved from the remote or root commit as usual.How did you verify your code works?
Ran a private server against a repo whose cache file is 40 NUL bytes. On dev, loading that directory returns a 500 with a "without null bytes" error; on this branch it resolves to the root commit ID. Typecheck,
bun run checkand the project tests pass.Checklist