itest: boot piri on Postgres so the stack comes up; accept any 2xx CORS preflight

[bajtos]

Fixes #45. The itest suite is green again — see the note below, because the root cause is not the one #45 diagnosed.

The failure was stack boot, not the CORS test

Every top-level itest failed, and none of them reached an assertion:

Error: initializing piri node: ... ProvideHarmonyDB ...
curio PDP pipeline requires Postgres (set database type to postgres)

Since piri:main absorbed Curio (~2026-07-24) its PDP pipeline refuses sqlite, and forgeStack booted sqlite piri via the zero-value PiriNodeConfig{}. This is pre-existing on main: main's own last itest run (c57186b4, the #42 merge this branch is based on) fails identically — same four suites, 24 occurrences of that error.

All four suites route through that one constructor, so the fix is one line: stack.WithPiriNodes(stack.PiriNodeConfig{Postgres: true}). The pinned smelt already supports it (PiriNodeConfig.Postgres → manifest.DBPostgres), so no dependency bump is involved.

Correction to the #45 diagnosis: the versitygw pin is fine

#45 concluded that the pinned versitygw v0.0.0-20260716095011 predates the CORS work and that the fix required bumping to a fork build with preflight support. That isn't the case — that exact module version already ships the whole stack:

• OPTIONS /:bucket and /:bucket/* routes (s3api/router.go:1547-1561)
• the CORSOptions controller (s3api/controllers/options.go)
• ApplyBucketCORS on every bucket/object route, and ApplyBucketCORSPreflightFallback

Reproducing the itest's exact requests against an in-process server (real versitygw s3api + ingot's config→CORS-document path) shows every header assertion already passing on the current pin: Allow-Origin echoed on the https://*.dev.example wildcard match, Allow-Methods including PUT, Max-Age 600, a bare 403 for a disallowed origin, and Expose-Headers including ETag on a presigned cross-origin GET. No versitygw bump is needed.

The one genuine test defect was the status: versitygw's ProcessController renders every successful controller response as 200 unless MetaOptions.Status is set, and CORSOptions doesn't set it. 204 is only what the no-CORS-config fallback returns — a path ingot never takes, since it reports a CORS configuration for every bucket.

So the assertion now accepts any 2xx, the fetch spec's "ok status" range. Nothing is lost in strictness: the Max-Age == "600" check is what actually pins the real CORS path, because the fallback sets no Max-Age and mirrors the requested method instead of the rule's method list.

Overlap with #44

#44 independently arrived at both of these same changes (piri-on-Postgres, and the 2xx relaxation) as incidental fixes alongside its catalog-retention work. The overlap resolves trivially whichever lands first. #44's note that TestForgeReadAfterEviction would still fail on an upstream piri did:plc proof-verification problem did not reproduce here — it passed in 127.66s.

Verification

itest job green on 574a0a5 (run 30366470280), all four suites passing and TestForgeScenarios/CORS genuinely running rather than skipped:

--- PASS: TestForgeReadAfterEviction (127.66s)
--- PASS: TestForgeNativeProvision (48.71s)
--- PASS: TestForgeScenarios (50.76s)
    --- PASS: TestForgeScenarios/CORS (0.08s)
--- PASS: TestForgeVersity (92.62s)

Zero failures; the remaining skips are the pre-existing curated XFail rows and the documented position-dependent cases. Unit suite green on all three platforms, gofmt clean, go vet -tags itest ./itest clean.

[Copilot]

Pull request overview

Updates the Forge integration scenario test to expect a 200 OK response for a successful CORS preflight, aligning the test with observed S3-style behavior and typical browser expectations for OPTIONS preflight handling.

Changes:

• Update the TestForgeScenarios/CORS preflight status assertion from 204 No Content to 200 OK.
• Add an explanatory comment clarifying why 200 is expected for a matched preflight.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bajtos]

It would be great to change stack.WithPiriNodes to configure Postgres by default. Perhaps as part of the larger cleanup to remove SQLite from Piri & Smelt.

[bajtos]

Agreed that's the right end state — but WithPiriNodes / PiriNodeConfig live in fil-forge/smelt, so flipping the default can't land in this PR. Keeping this one line here is the minimum to get a red suite green against the smelt version ingot currently pins.

Worth noting for whenever the smelt cleanup happens: this line can't rot silently either way. If smelt just flips the default, Postgres: true becomes redundant but stays correct. If the field goes away entirely along with sqlite, this becomes a compile error at bump time — so it surfaces immediately rather than quietly reverting the suite to sqlite.

Happy to pick up the smelt-side change (invert or drop the field, then drop this argument here) as a follow-up if you want to point me at it — it's outside this repo, so it needs its own PR there.

---

Generated by Claude Code

[alanshaw]

This was resolved in #46