C-105: a torn run says what it left behind

[Polichinel]

The gap, precisely

The contract already handles the consumer's side of a mid-upload failure correctly and by design: the manifest is uploaded last, so an attempt that dies before it has no commit marker and is invisible rather than half-visible (§4.2). Nothing partial is served.

Our side was the gap. C-105's own words: "the k uploaded objects remain, nothing records that they exist, and nothing removes them." An operator was left to diff the bucket by hand, and at run-0 scale a retry adds ~110 more under the same names.

What changed

deliver_run keeps an in-memory ledger alongside the log line, and any failure in the upload phase raises TornRunError naming the run, how many of how many objects landed, and their names and file ids.

The message states three things an operator would otherwise have to establish themselves:

• the consumer cannot see this run — the manifest never landed, so nothing partial is being served. Usually their first question.
• the listed objects are still there and were NOT removed. A reader who assumes cleanup happened will not go looking.
• a re-run uploads all of them again under the same names, and whether the store supersedes or duplicates is a semantic this repository does not assert. That is a decision to take before re-running.

What this deliberately does not do

It deletes nothing. Removing objects from a partner bucket is irreversible and an operator decision rather than a delivery-path one, and the neighbouring delete surface is its own open question (C-58, views-pipeline-core #333, blocked on a test key).

So C-105 stays open with a Partial mitigation: the mess is now legible, and it is still a mess. Closing it needs a decision about who cleans up and whether the store supersedes — neither of which is engineering work here.

Verification

tests/test_torn_run.py — 5 tests, mutation-proven both ways:

mutation	result
drop the try/except, let the raw error escape	4 failed
stop recording what landed	3 failed
neither	5 passed

Suite: 458 passed, 3 skipped, 37 xfailed. The 26 failures are the C-104 venv drift, green in CI. ruff clean.

[Polichinel]

Review round — /review-diff + /code-review high

Nine findings across the two passes. Three of them would each have sent an operator the wrong way, which is a bad property for a message whose only job is to direct one.

The one that mattered — HIGH

The refusal omitted the object that failed — and that object is the likeliest orphan of the entire run.

_ContractStorePort.upload raises precisely in the case its own comment documents:

the store logs, then RETURNS success=False with the file already uploaded

So the failing object is the C-79 shape — sitting in the bucket with no metadata document — while my message listed only the successes and presented that as what remains. An operator trusting it would walk straight past the orphan this change exists to surface.

The other two that misdirect

• File ids were truncated to five and recorded nowhere else. The log ledger carried name, doc_type and run_id but not file_id, so at run-0 scale ~104 ids existed only in a truncated string nobody kept. The ledger line now carries file_id and is the persistent record.
• A failure on the first upload — expired credentials, unreachable bucket, the commonest infrastructure failure there is — printed Already in the partner store, and NOT removed: . An empty list and a dangling period, presented as a bucket to audit.

And three smaller

#	finding	fix
4	"the consumer cannot see this run" asserted categorically — the code cannot know it, since a manifest upload can fail after the store committed the document, in which case the consumer is being served and a re-run duplicates everything	softened to "almost certainly", with an instruction to verify
5	TornRunError inherited SinkError — "cannot be delivered as declared", i.e. do-not-retry. A tear is transient with the opposite semantics, and test_hop_b_sink_e2e already uses pytest.raises(SinkError) as the malformed assertion	re-based on RuntimeError, matching delivery.findability
6	test module reached into test_hop_b_sink_e2e for a private helper; missing blank lines	self-contained, lookup derived from gaul_schema

Recorded, not fixed

The historical leg is outside the wrapper. It uploads after the wire run is committed, so a failure there leaves a visible, complete forecast run beside the previous run's historical artifact — the one tear where "the consumer cannot see this run" would be false. The wrapper does not fire there, so nothing says anything wrong; the gap is that nothing says anything at all. Registered as remaining scope in C-105 and the CIC rather than widening this change — the manager is at 435/450 of its line budget and it belongs with whoever takes the deletion decision.

Verification

mutation	caught
drop the try/except	4 tests
drop the ledger	3 tests
drop the orphan caveat	2 tests
re-base on SinkError	1 test

CI: 485 passed, 5 skipped, 37 xfailed, 0 failed.