Introduce a service-wide data-version stamp #19

Closed
opened 2026-07-01 00:58:00 +00:00 by manlycucumber · 1 comment
manlycucumber commented 2026-07-01 00:58:00 +00:00 (Migrated from github.com)

Problem

Because responses are immutable per key, the only correct way to invalidate everything after a Core/text change is a single data-version stamp baked into keys and payloads. This stamp is the linchpin of the cache contract.

Acceptance criteria

  • A single data-version value is exposed in every response and incorporated into cache keys.
  • Bumping the version produces new cache keys for all responses.
  • The current version is readable via a lightweight endpoint.
  • Version propagation is covered by tests across static and dynamic paths.

Notes

The data-version is the global invalidation lever for the whole API surface.

## Problem Because responses are immutable per key, the only correct way to invalidate everything after a Core/text change is a single data-version stamp baked into keys and payloads. This stamp is the linchpin of the cache contract. ## Acceptance criteria - [ ] A single data-version value is exposed in every response and incorporated into cache keys. - [ ] Bumping the version produces new cache keys for all responses. - [ ] The current version is readable via a lightweight endpoint. - [ ] Version propagation is covered by tests across static and dynamic paths. ## Notes The data-version is the global invalidation lever for the whole API surface.
manlycucumber commented 2026-07-03 05:57:42 +00:00 (Migrated from github.com)

Delivered in #136 (squash-merged to develop).

Delivered in #136 (squash-merged to `develop`).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Directorium/Api#19
No description provided.