Stop setting the canonical-modules flag Grail has retired - #12
Merged
Conversation
CI went red on all three platforms, on a branch that touched none of
this:
a importlib class does not understand #'___canonicalClassesEnabled___:'
Stopping at line 87 of /tmp/gemdb-it-…/bin/gemdb-run.tpz
Grail 18f0bb40 retired the flag: warm binding is now its only path, and
what is warm is decided by what has been committed. bundle:grail clones
Grail's default branch, so CI builds a payload without the selector while
the extension still sends it -- which is the early warning that job is
for, working exactly as intended.
Two senders, and only one was survivable. session.ts sent it guarded and
caught the DNU, so the extension merely logged a failure on every login;
gemdb-run.tpz sent it bare, so every file run died at that line -- the
whole CLI, including the demo scripts. Both are gone. The behaviour they
asked for is what the shipped extent already provides.
Verified the way CI does rather than against the pinned payload: rebuilt
grail/ from Grail HEAD (dab4588) and extent/ from that, then ran the
integration suite -- 46 passing. Worth recording that the old payload
gives the opposite result: with the flag still present and defaulting
off, removing these sends fails 5 tests, because imports go cold and
sessions arrive dirty. The extension and its payload are a matched pair
and this change is only correct for the new half.
Checked while here: Grail's change does not fix the separate runPath gap
-- a file run is still dirty at line 1 and a transaction block still
cannot be a script's first statement -- so the Known gap in the demo
stands. CLAUDE.md's note on it no longer cites the retired selector.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1 participant
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.
CI is red on
mainfor every new branch, including one that touches none of this:Grail
18f0bb40retired the flag — warm binding is its only path now, and what is warm is decided by what has been committed.bundle:grailclones Grail's default branch, so CI builds a payload without the selector while the extension still sends it. This is precisely the early warning that job exists for, doing its job.Two senders, one fatal
session.tsgemdb-run.tpzgemdbCLIBoth are gone. The behaviour they asked for is what the shipped extent already provides.
Verified the way CI does, not against the pinned payload
Rebuilt
grail/from Grail HEAD (dab4588) andextent/from that, then ran the integration suite: 46 passing.Worth recording the opposite result, because it is the thing to remember: against the old payload — flag present, defaulting off — removing these sends fails 5 tests, since imports go cold and sessions arrive dirty. The extension and its payload are a matched pair, and this change is correct only for the new half. That is why it cannot be verified against a stale local
grail/.Checked while here
Grail's change does not fix the separate
runPathgap: a file run is still dirty at line 1, andwith gemdb.transaction():still cannot be a script's first statement. So the "Known gap" indocs/demo-rabbit-in-the-hat.mdstands, and CLAUDE.md's note on it no longer cites the retired selector.Merge order
This unblocks everything. #11 (the first-run ENOENT fix a user reported) is red only because of this, and goes green once this lands and it rebases.
109 unit tests, 46 integration. Lint, format, both typechecks clean.
🤖 Generated with Claude Code