From e1a74edf159b37450d8f6c896e6e1ad9e916addb Mon Sep 17 00:00:00 2001 From: Polichinl Date: Tue, 29 Sep 2026 22:36:26 +0200 Subject: [PATCH 1/2] fix(#439): bump VIEWS_POSTPROCESSING_PIN 1.1.1 -> 1.4.0 in both launchers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Closes #439. Two lines, one value, and it is the only thing standing between the FAO findability fix and a pod. WHY THIS IS NOT A NO-OP. The launcher does NOT install views-postprocessing from PyPI. It installs from a git ref: tools/launcher/postprocessor.sh:132 pip install "git+https://${GITHUB_TOKEN}@.../views-postprocessing.git@${VIEWS_POSTPROCESSING_PIN}" and refuses the run at :164 if the installed ref does not match the pin. So views-postprocessing#314 being merged does nothing for a pod, and releasing it to PyPI (1.4.0 is there) does nothing either. Verified empirically rather than reasoned: the 2026-09-29 pod ended up with views-postprocessing 1.1.1 while PyPI was at 1.3.0. This was invisible because the two halves of the same incident reach a pod by DIFFERENT mechanisms — views-pipeline-core transitively from PyPI through views-hydranet's dependency range, views-postprocessing from a git tag by exact pin. "Is the fix released?" therefore has two different correct answers depending on which half is meant, and nothing states that anywhere. views-postprocessing#310 is the same family. WHAT 1.4.0 CARRIES: #314, the C-94 findability guard that verifies every artefact by name rather than trusting a returned file id — the defect that let the 2026-09-29 delivery report "Postprocessor Run Completed" while being unservable; and #315, a guard deriving the port's documented datastore contract from source so the prose cannot drift from the code. VERIFIED BEFORE COMMITTING, not assumed: - tag 1.4.0 resolves on the remote the launcher actually pulls from (8db8c9fb) - no other reference to 1.1.1 remains in the repo outside historical reports - the ref-vs-pin guard at postprocessor.sh:164 still reads the same variable - `bash -n` clean on both files BOTH LAUNCHERS, deliberately. un_crafd carries the identical pin and the identical exposure; leaving CRAF'd on 1.1.1 would fix one partner delivery and silently leave the other on the version with the defect. NOT pinned to `development`, which would have been the lazy choice and is worse than a moving target here: the :164 guard compares the installed ref against the pin STRING, so a branch name satisfies the check designed to catch staleness while installing whatever landed most recently. It would pass the guard and still be unreproducible for a partner-visible delivery. Expect a behaviour change: a delivery that previously completed can now stop. 1.4.0 adds two refusal situations and no new exception types. A DeliveryNotFindableError names every object that does not resolve and states explicitly when nothing in the run is servable. Edited under an explicit lift of the standing "do not modify run.sh" rule, granted for this change. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01GG2cY2HaqmUMpwUyR5V82K --- postprocessors/un_crafd/run.sh | 2 +- postprocessors/un_fao/run.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/postprocessors/un_crafd/run.sh b/postprocessors/un_crafd/run.sh index eb097efd..6c318ac5 100755 --- a/postprocessors/un_crafd/run.sh +++ b/postprocessors/un_crafd/run.sh @@ -31,7 +31,7 @@ POSTPROCESSOR_ENV_NAME="views-postprocessing" # #268) — the defect that killed this launcher's first delivery attempt on 2026-08-13. # Both launchers moved together; leaving either on 1.1.0 re-creates the downgrade path # described above, now with un_crafd armed as well. -VIEWS_POSTPROCESSING_PIN="1.1.1" +VIEWS_POSTPROCESSING_PIN="1.4.0" script_path=$(dirname "$(realpath "$0")") # shellcheck source=../../tools/launcher/postprocessor.sh diff --git a/postprocessors/un_fao/run.sh b/postprocessors/un_fao/run.sh index c15542e4..6279deb0 100755 --- a/postprocessors/un_fao/run.sh +++ b/postprocessors/un_fao/run.sh @@ -35,7 +35,7 @@ POSTPROCESSOR_ENV_NAME="views-postprocessing" # python -c "import views_postprocessing, pathlib; \ # print(pathlib.Path(views_postprocessing.__file__).parent / 'unfao/managers/unfao.py')" # grep -n 'success is not True' -VIEWS_POSTPROCESSING_PIN="1.1.1" +VIEWS_POSTPROCESSING_PIN="1.4.0" script_path=$(dirname "$(realpath "$0")") # shellcheck source=../../tools/launcher/postprocessor.sh From e957478f0e128bea94e58f0180ed64b5510f6e73 Mon Sep 17 00:00:00 2001 From: Polichinl Date: Tue, 29 Sep 2026 22:42:30 +0200 Subject: [PATCH 2/2] docs(#439): record WHY the pin moved to 1.4.0, in both launchers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit /review-diff on the pin bump, and the finding is one the value hid: the rationale blocks in both launchers document 1.1.0 and then 1.1.1 in detail, and stopped there. The value said 1.4.0 with no recorded reason. These blocks are not commentary. `tools/launcher/postprocessor.sh:26` says "EVERY STEP BELOW IS A SCAR. Read the comment before reordering anything." A future reader would have found a version two moves ahead of its own history and no way to learn what it carries. Which is the exact pattern the views-postprocessing session named against itself twice today — fixing the visible half of a finding and leaving the half that bites. The value is the visible half. The scar record is the half that explains it. un_fao now records the 2026-09-29 incident as the reason: the findability guard in 1.1.1 checked TWO artefacts out of the 110 a run uploads, and by returned file id rather than by name, so the first-ever FAO delivery uploaded 109 of 110, logged "Postprocessor Run Completed", fired a success alert and was refused by views-faoapi. It also records that the producer half of that defect is views-pipeline-core#552, shipped in 3.3.4 and reached from PyPI, while this pin is the other half and is reached from a git tag — which is precisely why "is the fix released?" had two different correct answers and this line was missed for hours. un_crafd records the same, framed by the shared-prefix argument its own block already makes twice: both launchers install into one conda prefix, so moving only the leg that failed downgrades the environment out from under the armed FAO delivery (C-139). CRAF'd runs the identical `_assert_delivery_is_findable`, so the defect is byte-identical there and has simply not fired on that leg yet — the same sentence the 1.1.1 note had to write about #268. Also replaced the verification recipe. The old one greps for `success is not True`, which verifies the 1.1.0-era C-79 fix and is still correct but says nothing about what 1.4.0 adds. The new one greps `DeliveryNotFindableError` in `delivery/findability.py` — verifying the build by what it REFUSES rather than by what it claims, which is the lesson of the whole incident. No behaviour change in this commit; the pin value is unchanged from the previous one. ruff clean, 8037 passed, `bash -n` clean on both files. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01GG2cY2HaqmUMpwUyR5V82K --- postprocessors/un_crafd/run.sh | 10 ++++++++++ postprocessors/un_fao/run.sh | 22 ++++++++++++++++++++++ 2 files changed, 32 insertions(+) diff --git a/postprocessors/un_crafd/run.sh b/postprocessors/un_crafd/run.sh index 6c318ac5..5224831d 100755 --- a/postprocessors/un_crafd/run.sh +++ b/postprocessors/un_crafd/run.sh @@ -31,6 +31,16 @@ POSTPROCESSOR_ENV_NAME="views-postprocessing" # #268) — the defect that killed this launcher's first delivery attempt on 2026-08-13. # Both launchers moved together; leaving either on 1.1.0 re-creates the downgrade path # described above, now with un_crafd armed as well. +# +# Moved to `1.4.0` on 2026-09-29 (#439), and the shared-prefix argument above is again the +# reason BOTH moved rather than only the leg that failed. 1.1.1's findability guard checked +# two artefacts out of the 110 a run uploads, by returned file id rather than by name — so +# the first-ever FAO delivery reported "Postprocessor Run Completed" while being unservable +# (views-postprocessing#314, and views-pipeline-core#551 for the producer half). CRAF'd runs +# the identical code down to the shared `_assert_delivery_is_findable`, so the defect is +# byte-identical on this leg and has simply not fired here yet — the same sentence the 1.1.1 +# note above had to write about #268. Leaving un_crafd on 1.1.1 would also downgrade the +# shared prefix out from under an armed FAO delivery, which is the C-139 path. VIEWS_POSTPROCESSING_PIN="1.4.0" script_path=$(dirname "$(realpath "$0")") diff --git a/postprocessors/un_fao/run.sh b/postprocessors/un_fao/run.sh index 6279deb0..39cfcea5 100755 --- a/postprocessors/un_fao/run.sh +++ b/postprocessors/un_fao/run.sh @@ -35,6 +35,28 @@ POSTPROCESSOR_ENV_NAME="views-postprocessing" # python -c "import views_postprocessing, pathlib; \ # print(pathlib.Path(views_postprocessing.__file__).parent / 'unfao/managers/unfao.py')" # grep -n 'success is not True' +# +# 4. Moved to 1.4.0 on 2026-09-29 (#439). 1.1.1's findability guard checked TWO artefacts +# — the manifest and the historical leg — out of the 110 a run uploads, and resolved +# them by a returned file id rather than by name. On 2026-09-29 the first-ever FAO +# delivery uploaded 109 of 110 objects, logged "Postprocessor Run Completed", fired a +# success alert, and was refused by views-faoapi: the GAUL sidecar's bytes matched the +# previous run's, the content-addressed store declined a second copy, and the uploader +# returned a real file id for the WRONG file. The manifest then named a file that did +# not exist. 1.4.0 carries views-postprocessing#314 — every artefact verified BY NAME, +# order-independent — and #315, which derives the port's documented datastore contract +# from source so the prose cannot drift from the code. +# +# The producer half of that defect is views-pipeline-core#552, shipped in 3.3.4 and +# reached from PyPI. This pin is the OTHER half and is reached from a git tag, which is +# why "is the fix released?" had two different correct answers and this line was missed. +# +# Verify this one the same way, by what it refuses rather than what it claims: +# +# grep -rn 'DeliveryNotFindableError' /delivery/findability.py +# +# Expect a behaviour change: a delivery that previously completed can now STOP. 1.4.0 +# adds two refusal situations and no new exception types. VIEWS_POSTPROCESSING_PIN="1.4.0" script_path=$(dirname "$(realpath "$0")")