Verified against main at 715c52e.
Impact
Repository detail entries are considered fresh solely from refreshedAt < 24 hours. The cache already records an activityAt value derived from the repository's latest pushedAt / updatedAt, but the read path never compares the cached marker with the current repository marker.
As a result, a push or newly updated pull request can be visible in the repository list while the cached latest commit/detail remains stale for up to a day. refresh=1 bypasses the five-minute dashboard cache but still reuses the one-day detail entry, so the user-visible Refresh action cannot correct it.
Concrete code references
Acceptance criteria
- A repository inside the scan set is revalidated when its current activity marker advances beyond the marker stored with a still-within-TTL cache entry.
- A full/forced dashboard load returns the updated surviving detail fields after such activity without requiring the 24-hour TTL to expire.
- Unchanged repositories continue to use the bounded one-day cache; this change must not turn Refresh into an unconditional all-repository fan-out.
- A failed revalidation preserves the last known value for the failed field, emits the existing sanitized partial-data warning, and remains eligible for retry.
- Existing out-of-scan warnings and hosted-vs-local cache boundaries remain intact.
Test expectations
- Add a fake-time server test that seeds detail cache, advances repository
pushed_at or updated_at within 24 hours, and proves the relevant upstream detail call and new payload value occur. - Add the inverse assertion that an unchanged activity marker performs no extra detail call.
- Cover partial refresh failure and retained prior data.
- Run
npm run test -- --project server and npm run check.
Dependencies / order
Implement after the public fan-out issue. If that issue removes latestPullRequest, apply activity invalidation only to the detail fields that remain in the final contract.
Non-goals
- Forcing every scanned repository to refresh on every button press.
- Removing the 24-hour cache or widening
scanLimit. - Refreshing repositories outside the bounded scan set.
- Adding a distributed cache.
Verified against
mainat715c52e.Impact
Repository detail entries are considered fresh solely from
refreshedAt < 24 hours. The cache already records anactivityAtvalue derived from the repository's latestpushedAt/updatedAt, but the read path never compares the cached marker with the current repository marker.As a result, a push or newly updated pull request can be visible in the repository list while the cached latest commit/detail remains stale for up to a day.
refresh=1bypasses the five-minute dashboard cache but still reuses the one-day detail entry, so the user-visible Refresh action cannot correct it.Concrete code references
refreshedAtandactivityAt.pushedAtandupdatedAt.Acceptance criteria
Test expectations
pushed_atorupdated_atwithin 24 hours, and proves the relevant upstream detail call and new payload value occur.npm run test -- --project serverandnpm run check.Dependencies / order
Implement after the public fan-out issue. If that issue removes
latestPullRequest, apply activity invalidation only to the detail fields that remain in the final contract.Non-goals
scanLimit.