[Christopher Plieger (cplieger)]

OwnerCache.LoadAndAcquire parses a new or expired entry while holding that entry's lock. In the extended config cache, the parse calls GetExtendedConfig for each config the entry extends, which calls LoadAndAcquire again. Two snapshots that enter a circular extends chain at different points then each hold one entry and wait for the other's, and neither createSnapshot returns.

Impact: an analyzer that opens a repository's projects concurrently on the API waits forever, with no error, on a repository where two configs extend into one circular extends chain at different points.

LoadAndAcquire still returns a live, unexpired entry under its lock. Otherwise it now parses with no lock held, then stores the value and adds the owner under the entry's lock. The one behavior change is that concurrent loads of one config that find no live, unexpired entry may each parse it. The first value stored wins, and a later parse is dropped when it finds a live, unexpired entry. The CLI's own extended config cache has the same pattern, reported in #64833, and #64835 fixes it the same way.

TestOwnerCacheConcurrentlyLoadKeysThatLoadEachOther loads a and b on two goroutines with a parse that waits until both loads have started and then loads the other key, as two configs of one cycle do. On main the two loads never return, and the test fails after 10 seconds with a deadlock message in 10 of 10 runs, plain and with -race. It drives the cache directly because a test of two concurrent snapshots hangs on main in only about 6 of 10 runs. TestOwnerCacheConcurrentLoadsKeepFirstStoredValue starts a slow parse of a, loads a again with a different value while that parse waits, and then lets it finish. All three loads must return the value of the load that stored first. On main the second load waits on the first parse's lock, and the test fails after 10 seconds in 10 of 10 runs. Because main stops there, I checked the case it guards on this change with every parse stored, where it fails in 10 of 10 runs because the slow parse replaces the first value. With a tsc built from this branch, the reproduction in the issue returns in all 100 rounds in 3 of 3 runs.

This replaces part of #64825. I met it while building deadset-ts, the TypeScript analyzer of deadset, on the TypeScript 7 API.

An AI coding agent wrote this patch. I have read, built and tested it and will handle the review.

• There is an associated issue in the Backlog milestone (required)
• Code is up-to-date with the main branch
• You've successfully run npx hereby test
• You've successfully run npx hereby lint
• You've successfully run npx hereby check:format
• There are new or updated tests validating the change

Fixes #65300

[Copilot]

🟢 Approval recommended

No active review issues are identified for the OwnerCache locking change intended to prevent deadlocks during concurrent loads.

No open issues 🎉

What changed in this PR

Fixes #65300 by moving OwnerCache parsing outside entry locks, preventing concurrent API snapshot creation from deadlocking when projects enter a circular extends chain.

Changes:

• Preserves locked access to live, unexpired cache entries while parsing misses and expired entries without holding a lock.
• Allows concurrent parses while retaining the first stored value if it remains live and unexpired.
• Adds regression tests for recursive concurrent loads and first-stored-value behavior.

File	Description
tsc/​internal/​project/​ownercache.go	Moves parsing outside entry locks and rechecks the cache before storing.
tsc/​internal/​project/​ownercache_test.go	Tests deadlock prevention and value retention during concurrent loads.

_{Review effort: Balanced}