Problem
PR #153 added HEAD-SHA revalidation for branch-referenced components in detectIncludeComponent (the hover path). However, the completion provider's findComponentInCache and the validation provider's cache lookup do not run the same checkBranchFreshness logic. After a branch moves, a user can briefly see fresh hover results but stale completions or incorrect validation diagnostics for the same component — the cache TTL still bounds the window, but the inconsistency is confusing.
Expected
Once any provider detects that a branch component's HEAD has moved and refetches, the updated entry is in the cache and all providers immediately use the fresh data.
Proposed
Apply checkBranchFreshness (or an equivalent lightweight check) at the completion and validation cache-lookup sites so all three providers stay in sync, or ensure a stale-detected refetch (on any provider) is visible to all subsequent lookups in the same event loop tick.
Priority
Nice to have — bounded by the 60s TTL.
Problem
PR #153 added HEAD-SHA revalidation for branch-referenced components in
detectIncludeComponent(the hover path). However, the completion provider'sfindComponentInCacheand the validation provider's cache lookup do not run the samecheckBranchFreshnesslogic. After a branch moves, a user can briefly see fresh hover results but stale completions or incorrect validation diagnostics for the same component — the cache TTL still bounds the window, but the inconsistency is confusing.Expected
Once any provider detects that a branch component's HEAD has moved and refetches, the updated entry is in the cache and all providers immediately use the fresh data.
Proposed
Apply
checkBranchFreshness(or an equivalent lightweight check) at the completion and validation cache-lookup sites so all three providers stay in sync, or ensure a stale-detected refetch (on any provider) is visible to all subsequent lookups in the same event loop tick.Priority
Nice to have — bounded by the 60s TTL.