Linked projects intermittently split out of their repo group while a server's repository identity is unresolved or expired #32347

Activity

1. PookMook commented on Nov 7, 2026

   

   PookMook

   on Nov 7, 2026

   Last edited by PookMook

   More actions

   This comment was generated by AI (Claude Code, Claude Opus 5.5), driven by a human (Arthur), and should be reviewed for accuracy.

   Another symptom of the same cause, on a single environment with no linked machines, through the HTTP shell endpoint.

   What we see

   We run a small CLI wrapper next to T3 Code (0.1.6, Linux). Every 5 minutes it reads GET /api/orchestration/shell and treats each project with a non-null repositoryIdentity as a repository it can work in. To that wrapper, projects keep vanishing and coming back even though nothing about them changes:

   07:41:31 now advertising resident-experience
   07:46:31 now advertising resident-experience, monorepo, nerdsniped
   08:06:31 now advertising resident-experience
   08:11:31 now advertising resident-experience, monorepo, nerdsniped
   08:51:31 now advertising resident-experience, nerdsniped
   

   It's the same getAvailable → peek → Cache.getSuccess path described above, this time from enrichProjectShells in orchestration-v2/http.ts. The server traces back it up: ProjectEnrichmentService.resolveRepositoryIdentity spans start in the same second as the wrapper's reads (for example 13:06:31 and 13:11:31 UTC). So the wrapper's own read found the entry expired, got null, and set off the refresh. Which projects drop depends on whether anything else read them in the previous minute.

   What this adds to the issue

   • This isn't only about linked environments. Anything that polls the shell less often than once a minute, through the API, sees repositoryIdentity: null for repositories whose remotes haven't changed.
   • HTTP clients can't tell "unknown" from "no repository". The HTTP shell response carries only repositoryIdentity, not repositoryIdentityResolved, so a client reading it has no way to tell the two apart.
   • fix(server): linked projects keep their repository identity while it refreshes #32359 fixes the once-a-minute case, but not the first minute after a restart. Every project is still null until its first lookup finishes, so a client that connects right after the server starts would still see none of them as repositories. Exposing repositoryIdentityResolved (or leaving repositoryIdentity out until it's resolved) on the HTTP shell would let clients wait instead of guessing.

   Versions checked

   The code involved (ProjectEnrichmentService.ts, its 1-minute DEFAULT_SUCCESS_TTL, and the HTTP enrichProjectShells) behaves the same in v0.1.6, v0.1.7 and 0.1.8-nightly.20261107.4314. The only change in that range is to tracing (#29640).

   Workaround on our side

   We are changing the wrapper to stop reading repositoryIdentity at all and instead decide a project is a repository by checking for <workspaceRoot>/.git itself.
2. matx-art commented on Nov 9, 2026

   

   matx-art

   on Nov 9, 2026

   More actions

   Another symptom of the same cause: the PR review guide refuses to start and shows the wrong error.

   PullRequestReviewGuideService.generate reads the project through ProjectService.getShell, so it gets the peeked identity. requireOwnRepository treats a null identity the same as a pull request from another repository. If nothing read the project in the previous minute, the first "Write review guide" fails with:

   Guides are written from this project's checkout, and this pull request is in another repository. Write it from a project that is a checkout of that repository.

   A retry a few seconds later works, because the failed call queued the refresh. Server traces on 0.1.7 (Linux, a GitHub pull request in the project's own repository):

   22:43:10.466  ws.rpc.pullRequests.generateReviewGuide           Failure in requireOwnRepository
   22:43:10.467  ProjectEnrichmentService.requestLane              enqueued, cache had no entry
   22:43:10.469  ProjectEnrichmentService.resolveRepositoryIdentity  Success, 0.17 ms
   22:43:21      ws.rpc.pullRequests.generateReviewGuide           Success, run started
   

   The MCP write_pull_request_guides handler (apps/server/src/mcp/toolkits/pullRequests/handlers.ts) does the same check on project.repositoryIdentity, so agents can get the same refusal.

   #32359 also fixes the once-a-minute case on these paths. It does not fix the first lookup after a server restart: the identity is still null, and the guide refuses with the "another repository" message. Two changes would close that gap:

   1. Where the identity decides an outcome, wait for it with ProjectEnrichmentService.readRepositoryIdentity instead of reading the peeked shell value.
   2. Give a null identity its own error, for example "Could not determine this project's repository. Try again."
3. juliusmarminge

   closed this as completedin #32359on Nov 10, 2026