Ask before installing newer Python support into a database that has it

[jgfoster]

For 1.7.0: an update no longer files newer Python support (Grail) into a database that already has it. It asks first, with a warning. gemdb.reinstallPythonOnUpdate is ignored for now.

Why

Filing Grail in rebuilds every Python runtime class (install.gs removes and recreates Grail's dictionaries), and objects already committed keep pointing at the old classes.

Measured (2026-10-15):

• Setup: a database populated under 1.6.0's Grail (beef473), with Brain Freeze seeded, a policy bought and a claim filed, plus synthetic data. Then 9fb5d23 filed in the way an update does.
• What broke: committed datetimes, dates, timedeltas, Decimals, tuples, sets, instances of user classes and a stored None no longer pass isinstance or compare, and arithmetic fails. Some comparisons end the script with an error except BaseException can't catch. Brain Freeze dies on its first request (meta path spec for 'datetime.timedelta' has no loader).
• What survived: dicts, lists, numbers and strings.
• Control: filing the same build in again breaks things the same way, so this is any reinstall, not this pin.
• Fresh database: on the new build, every check passed.

What changes

• Who is asked: ensureRunning asks with a modal warning when a person asked for the database: Start, a notebook cell, the Shell, Run or Debug File, and the setup commands. Install files it in; Keep Current, or dismissing the modal, starts on the Python support the database already has.
• Who is never asked: auto-start and the first-run pass, which never prompt, and AI-agent tool calls, which a modal would leave hanging. They start on the existing Python support. resumeRunning routes through ensureRunning only for a first install now.
• Remembered per build: a "keep" is recorded beside the database (.gemdb-grail-declined, next to the install-failure record), so a notebook doesn't ask on every cell. An update shipping a different build asks again, a fresh database starts without the record, and installing clears it.
• Taking it later: the status view's Python row and Reinstall the Python Execution Engine take the update later, and that command now gives the same warning, since a reinstall does the same damage. The row's tooltip says so.
• First install: unchanged and automated, since there's nothing in the database to break.
• The setting: gemdb.reinstallPythonOnUpdate stays in the manifest with a deprecationMessage, so existing values aren't reported as unknown. Its reader is gone, and its README row is replaced by a paragraph on the question.
• Docs: docs/automation-boundary.md records the step under Asked, with the measurement and the placement reasoning.

Declining is safe: staging happens only on first setup and inside fileInGrail, so the Grail on disk and the Grail in the database stay the same build. CI on main has been running 1.7.0's extension code against beef473.

Tests

databaseStarted.test.ts covers:

• asks, with a modal warning
• No keeps the current Python support and still starts
• dismissing counts as no
• no repeat for a build already declined
• asks again for a different build
• never asks for auto-start or an agent
• ignores the old setting
• first install unasked
• the reinstall command warns and reinstalls only on yes

The two resumeRunning cases that tested the setting are replaced. Unit tests: 956 passed. Integration: 142 passed, plus the existing expected-fail and todo. Lint, format and both typechecks pass.

The changelog entry goes in the 1.7.0 release PR (#139), which already reorganises that section. Merge this first.

🤖 Generated with Claude Code