chore(witan-core): pin omnigraph to the released v0.10.0, off the edge tag - #311
Merged
Conversation
…ge` tag `edge` is force-updated on every push to upstream main, so a pinned digest describes a tarball that stops being downloadable the moment upstream merges. It broke twice on 2026-08-31 alone: `witan-code (code graph)` — the one job deliberately left uncached to report exactly this — was red on #300 and #302 at 11:32Z, went green when #305 refreshed the pin at 14:44Z, and was red again on #308/#309 by 20:13Z after four upstream pushes republished the assets. The refresh held about six hours. A fresh `witan setup` fails the same way, for the same reason. Upstream cut v0.10.0 at 21:29Z tagging a625748c8b, which is the same commit the then-current `edge` build came from, so this pins the same source under a name that cannot move rather than adopting a new one. That also ends the "temporarily on edge for a re-test" note above the version pin: the build under test now has a release. Four upstream commits arrive relative to the pinned ac620eea87. Only one carries operator consequence: #581 upgrades Lance to 11, which upstream says changes English stemming, so an index built by Lance 10 read with the Lance 11 analyzer silently under-returns. Every search()/bm25() query in read.gq sits on such an index. _OMNIGRAPH_INTERNAL_SCHEMA stays 6 and the storage-format gate stays green, so nothing catches this automatically — existing graphs need an explicit, per-branch `omnigraph rebuild-full-text-indexes`. Recorded in full above the digests. Verified against the v0.10.0 binary: witan-core 584, witan-council 1009, witan-code 580 — 2173 passed, no failures. The history block records how to run that honestly, since hermetic.py prepends the real ~/.local/bin and a PATH override alone silently tests the machine's existing binary instead.
Contributor
There was a problem hiding this comment.
Pull request overview
Pins OmniGraph to immutable release v0.10.0, replacing the unstable edge tag.
Changes:
- Updates release tags and verified asset digests.
- Keeps installer and Docker image pins synchronized.
- Documents the Lance 11 full-text-index migration requirement.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
packages/witan-core/witan_core/omnigraph_install.py |
Updates installer pins and migration history. |
docker/witan.Dockerfile |
Updates MCP image release pins. |
docker/omnigraph-server.Dockerfile |
Updates server image release pins. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
… terminal Copilot review on #311, and it corrects the premise of the pin commit. omnigraph 0.10.0 does not ship raw Lance 11's silent under-return. Upstream #581 added a guard: an index whose analyzer generation cannot be proven compatible raises FullTextIndexRebuildRequired — HTTP 409 with a `full_text_index_rebuild_required` detail — and their doc comment is explicit that ordinary reads stay available and a partial indexed result is never returned. So search fails closed rather than degrading quietly. The history block said the opposite and is corrected. That makes the client the problem. `classify_status` treats a bare 409 as RETRYABLE on the status alone — deliberately, so a lost CAS race is legible — and nothing above it matched this message. Every refused search()/bm25() would therefore be retried the full budget and surface as a timeout-shaped error, hiding the remedy the server already printed. Adds FULL_TEXT_REBUILD_REQUIRED, classified ahead of the 409 catch-all on the structured detail key and on the server's own prose, terminal on the first attempt on both transports. Not NEEDS_REPAIR: the graph is not damaged and `omnigraph repair --force` would be the wrong hammer. Regression tests cover both transports, that the detail key alone suffices, and that an ordinary lost-race 409 is still RETRYABLE. All four fail without the classification. witan-core 588, witan-council 1009, witan-code 580 — 2177 passed against the v0.10.0 binary.
blarghmatey
approved these changes
Aug 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What are the relevant tickets?
N/A — falls out of
witan-code (code graph)being red across open PRs.Description (What does it do?)
_OMNIGRAPH_RELEASE_TAGfromedgetov0.10.0and refreshes all three asset digests, inomnigraph_install.pyand both Dockerfiles together (just check-omnigraph-pinspasses).edgeis force-updated on every upstream push, so a pinned digest names a tarball that stops being downloadable the moment upstream merges. It broke twice on 2026-08-31:witan-code (code graph)— the one job deliberately left uncached to report exactly this — was red on chore(deps): update debian:trixie-slim docker digest to d7e1218 #300/chore(deps): update ghcr.io/astral-sh/uv docker tag to v0.12.10 #302 at 11:32Z, went green when chore(witan-core): refresh the omnigraph edge pins to ac620eea87 #305 refreshed the pin at 14:44Z, and was red again on chore: bump fastmcp floor to 4.0 GA, drop the 3.4.x straddle #308/feat(agent-config-kit): wire remote-server oauth through claude and pi adapters #309 by 20:13Z after four upstream pushes republished the assets. That refresh held ~6 hours. PRs currently showing green are holding results from before the move.v0.10.0at 21:29Z tagginga625748c8b— the same commit the then-currentedgebuild came from (comparereports identical). So this pins the same source under a name that cannot move; it is not an upgrade to something new.edge(0.10.0) for a re-test" note above the version pin. That note said to go back to 0.9.0 if the experiment had concluded; the build under test now has a release, so this answers it forwards.How can this be tested?
And the fetch that is currently failing now succeeds:
Full suites against the v0.10.0 binary: witan-core 584, witan-council 1009, witan-code 580 — 2173 passed, no failures.
testsupport/hermetic.pyprepends the real~/.local/bintoPATH, so putting a candidate binary earlier onPATHdoes not make the suite use it — the machine's installed omnigraph still wins and everything passes while proving nothing. Run withHOMEpointed at a scratch dir holding the candidate at$HOME/.local/bin/omnigraph, and the real~/.local/binoffPATHso only one omnigraph is reachable.Additional Context
The one thing worth a reviewer's attention — and it is not the digests.
Of the four upstream commits since the pinned
ac620eea87, three are inert here (a compiler typecheck tightening our.gqfiles already satisfy, upstream's own cross-version release qualification, and a bench test fix). The fourth is not:ModernRelay/omnigraph#581 upgrades Lance to 11, which changes the full-text analyzer.
Search fails closed — it does not degrade silently. (Corrected after Copilot's review; the first version of this PR said the opposite.) The silent under-return upstream cites (
organism,university) is what raw Lance does on a generation mismatch — #581 added a guard against it. 0.10.0 raisesOmniError::FullTextIndexRebuildRequired, HTTP 409 with afull_text_index_rebuild_requireddetail, and its doc comment incrates/omnigraph/src/error.rssays "Ordinary reads remain available; do not return a partial indexed result."So on a graph written before this binary: every
search()/bm25()query inread.gqis refused until rebuilt, and non-search reads are unaffected._OMNIGRAPH_INTERNAL_SCHEMAstays6and the storage-format gate is green — correctly, the on-disk format did not move.That 409 is why this PR is not digests alone.
classify_statustreats a bare 409 asRETRYABLEon the status (deliberately — it is what makes a lost CAS race legible), and nothing above it matched this message. An un-taught client would retry every refused search the full budget, then report a timeout-shaped failure that buries the remedy the server already printed.baa6a75addsFULL_TEXT_REBUILD_REQUIRED, matched ahead of the catch-all on the structured detail key and the server prose, terminal on the first attempt on both transports. Four regression tests, all failing without it.The remedy, per branch:
Upstream calls it a controlled cutover, not a rolling upgrade: stop old readers/writers and keep a recoverable backup first.
Nothing in this PR performs it. These constants only decide which binary a future install or image build fetches; merging changes no running system. The deployed graph needs that rebuild scheduled before it moves to an image built from this pin.
Checklist: