NEC-113: Directory manifest ETag hashes the timestamp and disk figures, so it rarely matches (flaky 304 test) #203
No reviewers
Labels
No labels
area:docs
area:identity
area:ops
area:plugin
area:server
channel:community
channel:direct
channel:owned
channel:press
channel:social
e2ee-constrained
gate:at-ga
gate:pre-ga
marketing
parity
relay:absent
relay:planned
relay:requested
relay:supported
risk:additive
risk:contract
risk:none
usability
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Nectenda/nectenda!203
Loading…
Reference in a new issue
No description provided.
Delete branch "worktree-nec-113-directory-manifest-etag-hashes-the-times"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Task: NEC-113 — https://projectron.nerchure.com/tasks/113
The shard's directory manifest ETag hashed the whole body, including generatedAt (a whole-second clock) and the capacity figures (which move with any disk write). So the identity service's conditional pull almost never got a 304, and directory-manifest.test.ts failed on CI whenever its two fetches straddled a second. That is FLAKE-8: tasks 425, 1536 and 1549, twice on main, where it blocked promotion. All three logged failures straddle a second boundary, and a forced boundary reproduces the 200 on the old code. The ETag now hashes the manifest minus generatedAt and capacity. A 304 carries the capacity figures in X-Shard-Capacity, and the identity service applies them when they are well formed, so its figures stay a minute fresh instead of freezing at the last directory change. New tests force the second boundary and a file-backed database's growth; both failed before the fix. Every rule was mutation-checked in both directions.
Spec:
docs/changes/NEC-113-manifest-etag/spec.mdChangelog
NONE