chore(omnigraph): run the 0.10.0 edge build to measure its effect on the write ceiling

[blarghmatey]

What are the relevant tickets?

tk-upstream-omnigraph-a-single-row-insert-costs-a-f-eeeae3, tk-concurrent-writes-to-the-deployed-witan-are-canc-02abbd, tk-omnigraph-conditional-write-cas-precondition-on--94155f, under wp-witan-multi-user-service-deployment-dcf6ee.

Description (What does it do?)

Pins all three omnigraph declarations to the upstream edge build (reports 0.10.0, 73 commits past v0.9.0), as a scoped experiment: the write path is what stands between this deployment and a team, and upstream main has landed insert-path work nobody has measured against our load.

Why this is cheap — which is the entire reason to try it

The v0.8.1 → v0.9.0 upgrade was expensive because the on-disk format broke: ~16 graphs per environment rebuilt via export → init → load, no downgrade, no canary. None of that applies. Verified before touching anything:

omnigraph 0.10.0 reads storage format 6, as declared.

Same format CI already runs. So this is a binary swap against the same store, and rollback is repointing the image.

Upstream publishes prebuilt binaries for every push to main (release-edge.yml force-updates the edge tag), so there is no source build involved.

Two pins, because the tag and the version genuinely differ

edge is a moving tag; the binary behind it reports 0.10.0, a version with no release to download. Folding both into one string breaks either the URL or the "already installed, skipping" check, which compares against what omnigraph --version prints. So:

• _OMNIGRAPH_RELEASE_TAG — where to fetch from (edge, or v<version> for a real release)
• _OMNIGRAPH_VERSION — what should come back (0.10.0)

just check-omnigraph-pins now enforces agreement on both, across all three files. Adding a second pin without extending that check would have recreated exactly the gap its own comment describes — the one that "went a full release cycle claiming the manager covered it when it did not".

⚠️ Known limitations of a moving tag

• The skip check weakens. Two different edge builds both report 0.10.0, so a machine that installed yesterday's will not fetch today's. Delete the binary when you need certainty. Documented at the constant.
• Renovate manages the VERSION line only, and a bump is not meaningful while the tag is edge. Pin a real v<version> before treating updates here as authoritative.
• edge is unreleased. Fine for CI and for measurement; not for Production.

What this is, and is not, expected to fix

In 0.10.0: graph-commit conditional writes (CAS, upstream #470), exact write receipts (#479), and real insert-path work — strict inserts staged without merge joins, the Lance 10 migration, branch-merge join/index-build cliffs removed, filter pushdown to the Lance scanner.

Not in it: cancellation shielding (upstream #490) and the async job API with request-key idempotency (#415) are still open PRs. Those two are what actually make a write's outcome knowable to the client — so this build is not expected to fix the indeterminacy, only possibly to move the knee.

If the answer turns out to be "no change", that is still worth having: it isolates the ceiling to the per-write cost and points squarely at #490/#415 landing upstream.

How has this been tested?

Everything below ran with the edge binary on PATH:

• binary-contract suite: 20/20 — the suite that caught 0.9.0's unannounced DateTime export wire change
• witan-core 466 passed
• witan-council 770 passed
• witan-code 516 passed
• just check-omnigraph-pins → omnigraph pins agree: 0.10.0 (tag edge)
• just check-omnigraph-format → omnigraph 0.10.0 reads storage format 6, as declared.
• prek clean

One test needed a note: test_pre_upgrade_candidates_exclude_the_current_binary fails when two omnigraph binaries are on PATH, because its premise is that the scan finds nothing but the current one. That is my local setup (edge + the installed 0.9.0), not a 0.10.0 incompatibility — re-run with a single binary on PATH, it passes. CI installs exactly one.

⚠️ Deploy note

The baseline to compare against, measured today at 3e8e3ff: 8 concurrent writers PASS clean; 24 writers FAIL with 23 of 24 committed-but-reported-failed; server-side handler durations 3s → 73s on one graph. The comparison run should use the same probe invocation so the numbers are directly comparable.

Deploying to CI restarts omnigraph-server (replicas=1, Recreate), the same window #5396 needs.

Does this change require a change to documentation?

No.

[Copilot]

Pull request overview

Pins Omnigraph to the rolling edge build for write-performance testing.

Changes:

• Separates release tag and reported version pins.
• Updates both container images to download from edge.
• Extends pin-consistency validation to include release tags.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
packages/witan-core/witan_core/omnigraph_install.py	Adds separate version and release-tag handling.
justfile	Validates tag and version agreement.
docker/witan.Dockerfile	Fetches the edge CLI binary.
docker/omnigraph-server.Dockerfile	Fetches edge server and CLI binaries.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.