Reported by a Lovable agent implementing CipherStash in a Lovable-hosted project. Its words: "My actual failure mode was subtle — the domains existed but their comparison functions didn't, so weight >= x errored at query time, long after 'install succeeded'."
The gap
Nothing checks that an EQL install is complete. The checks we have are:
isInstalled() (packages/cli/src/installer/index.ts:108-129) — do the two schemas exist. That is a presence test, not a completeness test.getInstalledVersion() (:132-166) — eql_v3.version(), falling back to 'unknown'.stash eql validate (packages/cli/src/cli/registry.ts:438-460) — validates the encryption schema against the EQL v3 vocabulary and against what the database has: missing columns, drifted domains, missing functional indexes. It checks the columns you declared. It does not check that the installed operator surface is internally coherent.
So a partial install — one where the domains landed and some of their supporting functions or operators did not — reports success at install time and fails at query time, on a specific predicate, in production-shaped code.
Proposal
stash eql verify (or a --surface mode on eql validate): assert that the installed EQL surface is complete and coherent, independent of any application schema.
For each domain the install claims to provide, assert its full expected set is present:
- the domain type itself,
- its term-extractor function (
eql_v3.eq_term / ord_term / match_term overload for that domain),
- its comparison operators,
- the operator class, where one is expected.
Report per-domain, and distinguish expected absence from damage. The ORE operator class is legitimately skipped on managed Postgres (see #759 and the ORE-fallback issue) — that is a supported configuration and must read as such, not as a failed install. Anything else missing is a broken install and should exit non-zero.
The whole check is catalogue queries against a known manifest of what the pinned bundle installs; it should run in seconds, and is worth running automatically at the end of stash eql install.
Caveat on the report
The agent named eql_v3_double_ord specifically as the domain whose comparison functions were absent. We have not reproduced that, and it may be a consequence of the rolled-back install it was fighting at the time (see the owner-scoped-grants issue) rather than a defect in the bundle. The class of failure — "install succeeded, query-time surface incomplete, nothing detected it" — is the thing to fix, whatever the specific cause was here. Reproducing the exact case would be a useful first step.
Related
Reported by a Lovable agent implementing CipherStash in a Lovable-hosted project. Its words: "My actual failure mode was subtle — the domains existed but their comparison functions didn't, so
weight >= xerrored at query time, long after 'install succeeded'."The gap
Nothing checks that an EQL install is complete. The checks we have are:
isInstalled()(packages/cli/src/installer/index.ts:108-129) — do the two schemas exist. That is a presence test, not a completeness test.getInstalledVersion()(:132-166) —eql_v3.version(), falling back to'unknown'.stash eql validate(packages/cli/src/cli/registry.ts:438-460) — validates the encryption schema against the EQL v3 vocabulary and against what the database has: missing columns, drifted domains, missing functional indexes. It checks the columns you declared. It does not check that the installed operator surface is internally coherent.So a partial install — one where the domains landed and some of their supporting functions or operators did not — reports success at install time and fails at query time, on a specific predicate, in production-shaped code.
Proposal
stash eql verify(or a--surfacemode oneql validate): assert that the installed EQL surface is complete and coherent, independent of any application schema.For each domain the install claims to provide, assert its full expected set is present:
eql_v3.eq_term/ord_term/match_termoverload for that domain),Report per-domain, and distinguish expected absence from damage. The ORE operator class is legitimately skipped on managed Postgres (see #759 and the ORE-fallback issue) — that is a supported configuration and must read as such, not as a failed install. Anything else missing is a broken install and should exit non-zero.
The whole check is catalogue queries against a known manifest of what the pinned bundle installs; it should run in seconds, and is worth running automatically at the end of
stash eql install.Caveat on the report
The agent named
eql_v3_double_ordspecifically as the domain whose comparison functions were absent. We have not reproduced that, and it may be a consequence of the rolled-back install it was fighting at the time (see the owner-scoped-grants issue) rather than a defect in the bundle. The class of failure — "install succeeded, query-time surface incomplete, nothing detected it" — is the thing to fix, whatever the specific cause was here. Reproducing the exact case would be a useful first step.Related
stash-encryption: the_ord_oredomains are not disabled on managed Postgres — only the opclass is skipped #759 — the_ord_oredomains are present-but-unindexable on managed Postgres, and the skill says otherwise. The verify command must encode the correct model, not the onestash-encryption: the_ord_oredomains are not disabled on managed Postgres — only the opclass is skipped #759 is fixing.*_ord_oredomains #629 — superuser-only ORE SQL coverage suite.