Archived
jschoubben
f5f860fd2b
`module forget` cascaded. The settings, the module's own secrets and the ports the mesh chose all name the module by a foreign key that cascades, so removing the row took all three and reported "forgotten" — an action succeeding into a state its own verify would reject (novox/hq 04-ISSUES/017). A sealed secret is not recoverable afterwards, because the mesh discarded the plaintext when it made it. It now reads what it would destroy, names each thing one at a time, and refuses. `--and-what-it-holds` is how somebody says they mean it, and the removal then reports what went — this being the only record that any of it ever existed. Reported as "operator settings do not persist, because re-registering a module cascade-deletes them". Half of that is wrong, and the test now says so out loud: the upsert is on the name, so `module add` at a new version leaves the settings, the secrets and the ports exactly where they were. The command that destroyed them was `forget`, and a wrong belief about which command destroys data is expensive in both directions — it sends people looking for a fault that is not there, and leaves the real one unexamined. Checked by internal/inventory/forget_test.go, which writes all three, re-registers the module at a new version, reads them back, and only then tries to forget it. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF