[blarghmatey]

What are the relevant tickets?

witan task tk-bump-the-omnigraph-pin-to-0-14-contract-0-14-sto-e7e5c7, the pin-bump step of the omnigraph 0.14 upgrade (spec in docs/internals/design/omnigraph-0-14-upgrade-spec.md, rollout step 3). Follows #564, #568, #569 and #571.

Description (What does it do?)

The installer and both images pin omnigraph 0.13.0 (storage format 14, HTTP contract 0.13). This moves all three to the released v0.14.0 assets (tag commit 60bfd19). The digests were hashed locally and matched against each published .sha256 and the release API. omnigraph version on the binary reads internal-schema 16 (serves v14 to v16) and http-contract 0.14, so _OMNIGRAPH_INTERNAL_SCHEMA and both image labels move 14 to 16 (the release notes say 15) and HTTP_API_CONTRACT moves to 0.14. The data-tier image now selects the patched CLI from #569 (OMNIGRAPH_CLI_SOURCE=patched), which check-omnigraph-pins requires once the release tag equals the patch base. The witan image and witan setup keep the stock release binary.

Both images also carry a new label, edu.mit.ol.omnigraph.min-internal-schema (14). It's the low end of that served range, declared as _OMNIGRAPH_MIN_INTERNAL_SCHEMA and checked against the binary by check-omnigraph-format and across all three declarations by check-omnigraph-pins. ol-infrastructure's preview guard refuses any image whose internal-schema label differs from the stack's served format, so the 16 label alone fails every stack still on fmt14. mitodl/ol-infrastructure#6801 makes the guard accept a served format anywhere in the image's range.

Merging this is one-way for any graph once 0.14 publishes to it. 0.14 opens a format-14 graph in place, but the first write a 0.14 binary makes stamps that branch 16, and every 0.13 binary refuses it from then on. So this has to merge in the cutover window, and there is no rollback short of restoring the pre-cutover backup.

Merging also auto-deploys CI's pulumi-omnigraph and pulumi-witan in no fixed order, and publishes witan-core 0.50.0 to PyPI. A 0.13 server and a pinned 0.14 client refuse each other's contract header, but #580 (stacked on this branch) makes witan-core negotiate the contract per server, 0.14 or 0.13, so the two stacks can deploy in either order and the merge doesn't need witan's CI deploy paused. The ol-infrastructure council probe pins 0.13 until mitodl/ol-infrastructure#6811, which makes it discover the contract the same way, is deployed. The published witan-council 0.46.0 (witan-core>=0.48,<1) and witan-code 0.27.1 (>=0.46,<1) resolve 0.50.0 on a fresh install or upgrade. That doesn't put the 0.14 contract on any deployed data tier: omnigraph-server is ClusterIP-only with no HTTPRoute (ol-infrastructure applications/witan/ci_indexer.py), so users reach it only through the deployed witan MCP tier, whose image builds from this workspace. What it does change is local: witan setup installs the 0.14 binary, which stamps a developer's local stores 16 on their first write.

Two client changes ride along, because the 0.14 CLI breaks the existing failure handling:

• 0.14 prints the resolved target on stderr for every call (target <store> (inline): direct graph …), so stderr is never empty. _cli_failure classified stderr whenever it had text, so every read's JSON error object on stdout (a recovery barrier, a conflict, an unreachable server) was classified from the target line alone and reported as fatal. This is what failed test_apply_schema_upgrades_an_old_store. The error object now wins whenever there is one.
• _classify_cli_error reads 0.14's exits (command_outcome.rs exit_for at v0.14.0). 2 (partial or unknown effects) is never retried, and a write raises WriteIndeterminate; it is checked before the retryable markers so a dropped connection can't turn it into a retry. 64 (a refused command line) is fatal. 75 now covers any refusal with effects: none, action: retry, so one that carries a 503 gets the unavailable-server budget rather than the admission cap's.
• The target lines 0.14 prints before every command (target <name> (<provenance>): ..., target write scope: branch=<name>) are kept in the message but left out of the classified text. They carry graph ids, branches and paths, and 0.13's --quiet that suppressed them is gone.

The 0.13-worded markers needed no change: 0.14 prints the same sentences with 0.14 in place of 0.13, checked on the binary and in graph_http.rs. witan-core is bumped to 0.50.0 here, and both servers' witan-core floors move to >=0.50 for the new contract.

A write whose HTTP error carries a 0.14 disposition with effects partial or unknown is now OUTCOME_UNKNOWN and raises WriteIndeterminate instead of being retried. 0.14 answers a load whose fork published before its rows were refused with a 409 that says partial, which the 409 rule would otherwise have replayed. A FATAL response is left alone: 0.14 reports unknown for every owned write that isn't a typed refusal, a plain 400 included, and group commit replays a FATAL composed group one write at a time. Whether that replay is safe stays with tk-classify-omnigraph-failures-from-the-0-14-dispos-2ae3ca.

Test changes for 0.14:

• test_binary_contract.py gets a format-16 row, measured on 0.14.0 (every surface matches format 14), and addresses upgrade with --target as witan does.
• testsupport/omnigraph_server.py applies and force-unlocks with 0.14's --target, so the served tests run against a 0.14 server with the 0.14 contract.
• The bridge-recreate test used the drop of an indexed property, which 0.14 now does in place. It uses a String? to String change instead, which both 0.13.0 and 0.14.0 refuse in place (OG-MF-106 on 0.14.0; the test passes against both binaries).
• The s3 export proxy test pins a pre-0.14 CLI, since stock 0.14 opens no s3:// store and witan-core already tests that refusal.

How can this be tested?

Run against the 0.14.0 binaries (a scratch HOME whose ~/.local/bin holds the release's omnigraph and omnigraph-server, TMPDIR on disk):

• just test-all: witan-core 888 passed, 7 skipped; witan-council 1801 passed, 4 skipped, 1 failed; witan-code 711 passed, 1 failed; agent-config-kit 564 passed; ol-agent-kit 1 passed. The two failures are harness-only: test_pre_upgrade_candidates_exclude_the_current_binary (two omnigraph binaries on PATH under the scratch HOME) and test_rebuild_refuses_a_file_path_with_real_git (a long TMPDIR wraps the asserted phrase). Both pass in the default environment. The served group-commit and branch-view tests ran against a real 0.14 server.
• The bridge tests in witan-code/tests/test_store.py also pass against the 0.13.0 binary.
• just check-omnigraph-pins, just check-omnigraph-format, just check-versions, just docs-check and uv run prek run --all-files pass.
• just check-core-floor passes against the bumped workspace witan-core.
• For the min-format label: just check-omnigraph-format --binary <0.14.0> reports "opens 14 to 16 in place, as declared", and test_omnigraph_install.py covers the 0.14 and 0.11 version lines. After the label commit, witan-core's suite was re-run with the 0.13.0 binary on PATH: 880 passed, plus one expected failure (test_the_binary_on_path_is_the_declared_format, which needs 0.14). check-omnigraph-pins, check-versions, docs-check and prek on the changed files pass too.

Not verified here: the Concourse image builds (the patched CLI stage was qualified by omnigraph-cli-patch.yml in #569), and anything against a deployed data tier. The cutover itself is tk-cut-over-ci-qa-then-production-to-omnigraph-0-14-be7663.

Checklist:

• feat(omnigraph): accept in-place format upgrades, guard the rollback ol-infrastructure#6801 merged, so CI's omnigraph preview accepts the 0.14 image on fmt14
• tk-spike-let-witan-core-negotiate-the-omnigraph-htt-3c94fb settled: go
• feat(omnigraph): negotiate the HTTP contract per server #580 merged into this branch, so witan can deploy before or after the data tier without a manual pause
• Merge only in the cutover window

https://claude.ai/code/session_01FGZebFvLxbZTiKey4rCL6B

[Copilot]

🟡 Changes recommended

Writes with unknown effects can be replayed, the core-version mismatch leaves dependency checks failing, and paths containing spaces can cause incorrect retries.

3 open issues

• Bump witan-core to 0.50.0 and update lockfile · New
• Honor unknown write effects on HTTP 409 without retrying · New
• Prevent spaced paths from being misclassified as admission caps · New

What changed in this PR

Upgrades Witan’s Omnigraph integration to 0.14.0, aligning the installer, container images and HTTP client with storage format 16 and contract 0.14. This follows the earlier CLI-addressing, patched-S3 and remote-branch work and requires a coordinated data-tier-first cutover.

Changes:

• Updates binary pins, checksums and image labels; enables the patched data-tier CLI.
• Adapts CLI error classification to 0.14 output and exit codes.
• Raises both servers’ core dependency floors and updates compatibility tests and changelog fragments.

File	Description
testsupport/​omnigraph_server.py	Uses version-aware cluster targeting in served tests.
packages/​witan-core/​witan_core/​omnigraph.py	Handles 0.14 error output, target reports and exit codes.
packages/​witan-core/​witan_core/​omnigraph_install.py	Pins 0.14.0 assets and declares storage format 16.
packages/​witan-core/​witan_core/​omnigraph_http.py	Selects contract 0.14 and adds an unknown-outcome kind.
packages/​witan-core/​tests/​test_omnigraph.py	Covers 0.14 CLI failure classification.
packages/​witan-core/​tests/​test_omnigraph_http.py	Updates HTTP contract expectations.
packages/​witan-core/​tests/​test_binary_contract.py	Adds format-16 expectations and target-aware upgrade calls.
packages/​witan-core/​changelog.d/​20261029_125338_blarghmatey_omnigraph_0_14_pin.md	Records core compatibility and error-handling changes.
mcp/​servers/​witan/​tests/​test_remote_proxy.py	Explicitly selects the legacy dialect for S3 export coverage.
mcp/​servers/​witan/​tests/​test_group_commit_served.py	Uses shared HTTP contract constants.
mcp/​servers/​witan/​pyproject.toml	Raises the core dependency floor to 0.50.
mcp/​servers/​witan/​changelog.d/​20261029_125338_blarghmatey_omnigraph_0_14_pin.md	Documents the dependency and image updates.
mcp/​servers/​witan-code/​tests/​test_store.py	Uses a schema change that still requires bridge recreation.
mcp/​servers/​witan-code/​pyproject.toml	Raises the code server’s core dependency floor to 0.50.
mcp/​servers/​witan-code/​changelog.d/​20261029_125338_blarghmatey_omnigraph_0_14_pin.md	Documents the new compatibility floor.
docker/​witan.Dockerfile	Updates CLI pins, checksums and storage-format label.
docker/​omnigraph-server.Dockerfile	Updates server pins and selects the patched CLI.
docker/​omnigraph_server_entrypoint.py	Updates documentation for the default 0.14 image.
.github/​workflows/​omnigraph-cli-patch.yml	Updates comments describing patched-image builds.

_{Review effort: Balanced}

[feoh]

Code looks right. I checked the exit-code mapping against upstream exit_for at v0.14.0, and the digests against the release API. Two merge-time problems are inline. Minor items:

• The body is out of date: the witan-core bump is already done (47a9bdf), and f391196 fixes the deferred "HTTP still retries every 409" low, so tk-classify-omnigraph-failures-from-the-0-14-dispos-2ae3ca may be closable.
• Unchanged code, but it bites now: _download_omnigraph replaces any non-pinned binary, so an older witan's setup puts 0.13 back over 0.14. That build then refuses local stores already stamped 16. Recoverable from omnigraph-0.14.0, but there's no warning.

[blarghmatey]

@feoh On the minor items: the body is updated. tk-classify-omnigraph-failures-from-the-0-14-dispos-2ae3ca stays open, because f391196 closes only the HTTP 409 replay. The task still covers classifying on the disposition instead of message text, plus 0.14 reporting effects: unknown on a plain 400 that group commit then replays one write at a time. The _download_omnigraph downgrade is filed as tk-witan-setup-silently-downgrades-a-newer-omnigrap-6f7ce5.