fix(#439): bump VIEWS_POSTPROCESSING_PIN 1.1.1 → 1.4.0 in both launchers

postprocessors/un_crafd/run.sh

@@ -31,7 +31,17 @@ 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"
+#
+# 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")")
 # shellcheck source=../../tools/launcher/postprocessor.sh

postprocessors/un_fao/run.sh

@@ -35,7 +35,29 @@ 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' <that path>
-VIEWS_POSTPROCESSING_PIN="1.1.1"
+#
+#   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' <views_postprocessing path>/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")")
 # shellcheck source=../../tools/launcher/postprocessor.sh