mirror of
https://github.com/stablyai/orca.git
synced 2026-09-30 08:03:12 +00:00
Neil
fc69ec11c6
* perf(github): coalesce stronger refreshes after pending requests * fix(github): bound the refresh-upgrade wait so a strict caller cannot starve The upgrade loop retried forever: a caller wanting a stronger refresh waited for each weaker in-flight request, rechecked, and waited again. A repeating weaker refresh (the quiet-refresh interval) could therefore pin a forced noCache caller for the life of the process with no timeout or escape hatch. Wait out at most one weaker request — enough for peers to share the upgrade — then issue our own. Call counts are unchanged; progress is now guaranteed. Retargets the coordination test at that invariant instead of asserting that strict callers block until the weaker replacement finishes. * fix(github): let only a dedupe key's current request write its cache Bounding the upgrade wait fixed the starvation but opened a window the unbounded loop never had: a stronger request can now run beside a weaker one for the same key. Nothing fenced the cache writes, so whichever settled last won. A force-only work-item request does not pass noCache, so gh's own cache can answer it; settling after the noCache request buried the fresher rows under a new fetchedAt and isFresh then served them for the rest of the TTL. Checks rewound run state the same way, and a superseded project request could stamp its failure over a newer table at the known view key. Stamp each request with a monotonic id on its inflight entry and recheck ownership after the provider call, immediately before every cache write — the work-items entry, both project-view branches, and checksCache plus the PR status syncPRChecksStatus derives from it. That is the same ownership question the cleanup guard already asked, so the cleanup now reads the stamp too; the promise itself cannot be compared from inside its own initializer. The wait stays bounded and the twenty-one-caller upgrade still collapses to two provider calls.