Repository navigation
chore(register): C-73 — stale-run selection; and a correction to C-25 written today - #176
Merged
Merged
Conversation
… written today From /falsify on "there is nothing more to do in this repo", which the audit disproved. The finding itself is views-pipeline-core's C-241, relayed in #172 and unread here until the audit went looking. C-73 (Tier 2): pipeline-core's search_files_by_metadata was unpaged — Appwrite returns 25 rows by default and get_latest_file_id sorted THOSE, so with more than 25 matching documents it returned the newest of the oldest 25, staler every run. It reaches this repo because HOP_A_MANIFEST_FILTERS is broad by design and the store has no retention: every manifest ever published is a candidate. Shard lookups are name-scoped and resolve correctly FOR WHATEVER RUN WAS SELECTED, which is exactly why the failure is quiet — everything downstream of the selection is self-consistent. The partner receives a complete, valid, wrong-vintage delivery. Not this repo's defect and not its fix (it arrives with a pin bump, gated on pipeline-core #341). What IS ours: the register carried no record of it, and the broad-filter-newest-wins strategy is a choice this repo made. C-25 CORRECTED, not rewritten. I closed it earlier today as "superseded by mechanism" on the reasoning that "recency-based selection is not an operation the code can perform any more". That is false — source_selection.py:106 does exactly that. What manifest selection actually solved is the PRODUCER-IDENTITY half: the manifest declares its ensemble and every shard header is checked against it, so another producer's run cannot be selected. The RECENCY half was never solved; it moved from newest-payload-file to newest-manifest. The overclaim is left visible because it is more instructive than the conclusion. appwrite merged into C-07 rather than filed separately — same problem type (undeclared direct dependency arriving transitively), new location. But it is no longer "Tier 4-ish, resolve if the transitive guarantee is sufficient": pipeline- core is making appwrite an optional extra (#345), so the guarantee is being withdrawn deliberately, and this repo breaks at import when it lands. Register: 73 concerns, 26 open. Integrity guard green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
From
/falsifyon "there is nothing more to do in this repo" — which the audit disproved. The finding is views-pipeline-core's C-241, relayed in #172 and unread here until the audit went looking.C-73 (Tier 2) — the delivery can ship a stale run rather than failing
pipeline-core's
search_files_by_metadatawas unpaged: Appwrite returns 25 rows by default andget_latest_file_idsorted those, so with >25 matching documents it returned the newest of the oldest 25 — staler every run.It reaches us because
HOP_A_MANIFEST_FILTERSis broad by design and the store has no retention: every manifest ever published is a candidate. Shard lookups are name-scoped and resolve correctly for whatever run was selected — which is exactly why the failure is quiet. Everything downstream of the selection is self-consistent, so the partner receives a complete, valid, wrong-vintage delivery.Not our defect and not our fix (arrives with a pin bump, gated on pipeline-core#341). What is ours: the register carried no record of it, and broad-filter-newest-wins is a strategy this repo chose.
C-25 corrected — I got this wrong earlier today
I closed C-25 as "superseded by mechanism" reasoning that "recency-based selection is not an operation the code can perform any more."
It is exactly what the code does —
source_selection.py:106.What manifest selection actually solved is the producer-identity half: the manifest declares its ensemble, every shard header is verified against it, so another producer's run cannot be selected. The recency half was never solved — it moved from newest-payload-file to newest-manifest.
The overclaim is left visible rather than rewritten, because it is more instructive than the conclusion: a mechanism can dissolve one half of a hazard and leave the other standing, and "superseded by mechanism" is exactly the phrasing that hides it.
appwrite merged into C-07
Same problem type (undeclared direct dependency arriving transitively), new location. But no longer "Tier 4-ish, resolve if the transitive guarantee is sufficient" — pipeline-core is making
appwritean optional extra (#345), so the guarantee is being withdrawn deliberately and this repo breaks at import when it lands.Register: 73 concerns, 26 open.
🤖 Generated with Claude Code