Task · MDE-0041

Timestamp inventory cache entries when successful writes commit

Description

Wave 3 found inventory cache timestamps captured before lock wait and upstream fetch, then stored after the request. Contention or a slow request can consume the entry TTL before the data is available, causing an immediate refetch.

Acceptance Criteria

Definition of Done

Implementation Plan

Wave 2 L2: add failing table-driven lock-wait, slow-fetch, and failed-fetch tests first across all six inventory cache families; timestamp only successful cache commits; run focused checks and return evidence without tracker or external writes.

Implementation Notes

Wave 3 reproduced the pre-fetch timestamp pattern across six inventory cache families. A safe correction must update every successful commit path together and prove failures do not refresh timestamps.

Wave 2 red: test_successful_cache_write_timestamp failed for organizations with 100.0 versus the expected 250.0 commit timestamp. All six cache families now timestamp only after successful fetch and assignment. Green: 12 timing regressions, 6 failure regressions, 97 combined inventory tests, typecheck, and just check with 2913 passed.

Final Summary

Parked after audit. Resume with table-driven lock-wait and slow-fetch regressions for all cache families, then move each timestamp assignment to the successful cache commit.

Wave 2: moved timestamps for all six inventory cache families to successful commit time and added lock-wait, slow-fetch, short-TTL, and failure regressions. Verified by the inventory suite and just check.

View the source file on GitHub