TestForgeScenarios/CORS has never passed: preflight support missing from the pinned versitygw

[frrist]

Summary

TestForgeScenarios/CORS (added by #42 / #43) fails on every stack that can actually run it:

scenarios_test.go:295: preflight status = 200, want 204

The test asserts that an unsigned browser preflight (OPTIONS with Origin + Access-Control-Request-*) is answered with 204 plus allow-list headers derived from cors_allowed_origins. Per the test's own comment, none of that behavior lives in ingot code — it's expected from versitygw's preflight route and per-route CORS middleware. But ingot pins github.com/fil-forge/versitygw v0.0.0-20260716095011-7a65883d595a (July 16), which predates the CORS work, and the fork's history has no CORS/preflight commits at all (latest activity: July 3–5 upstream syncs). The gateway answers the preflight 200 without CORS headers, so the test cannot pass against any currently published dependency set.

Why this landed: it was merged over a failing CI

Neither #42 nor #43 ever had a green itest run. The failure was seen and dismissed at merge time — #42 (comment):

Ignoring the test failure, it seems to be caused by broken Smelt that's using Piri with sqlite which is no longer supported after Curio was incorporated into Piri.

The diagnosis of the boot failure was accurate (since ~July 24, piri:main's Curio merge refuses sqlite and the itest harness booted sqlite piri, so the whole suite died at stack boot). But a red CI is a merge blocker, not a judgment call — "the failure is probably infra" is exactly the reasoning a CI gate exists to forbid, because a suite that never runs can't distinguish infra red from feature red. And in this case it didn't: the new test's own failure was sitting inside the same red, and these PRs merged a test that has never passed in any environment.

The correct sequence was: fix the harness first (it was a one-line topology default — see #44), get a green baseline, then merge the feature against it. Merging unverified tests over a broken suite converts CI red from "signal" to "background noise" and pushes the debugging cost onto whoever restores the suite — which is how this was found, days later, at the bottom of an unrelated investigation.

Fix options

1. Bump the versitygw pin to a fork build that implements the preflight route + CORS middleware the test asserts (if that work exists on an unmerged fork branch, land it first), or
2. If preflights are intended to be answered by the Caddy layer in front of ingot (Add CORS support to S3 listener with origin pattern matching #42's deployment config), adjust the test to target that layer or relax it to what the embedded gateway itself guarantees.

Process note

Two cheap guards would have prevented this class of miss: treat "itest cannot boot the stack" as a stop-the-line failure distinct from test failures, and pin the stack's service images by digest in CI so mutable :main tags can't invalidate the suite between runs.

Related: #42, #43 (introduced the test), #44 (restored itest bootability, exposing this).

🤖 Generated with Claude Code