mirror of
https://github.com/hanzoai/insights.git
synced 2026-10-30 16:15:31 +00:00
zeekay
eef5eeff1d
Three things the earlier ee work left open.
THE GATE COULD STILL PASS AN ee IMPORT. check-imports-are-committed carried `ee`
inside FIRST_PARTY, so the verdict depended on whether the import RESOLVED —
which is only false while the tree happens to be absent. Commit an ee/ and the
check goes green on the very thing it exists to stop. FIRST_PARTY answers "is
this committed"; `ee` is not missing, it is refused, so it is now its own
question and the answer does not consult the filesystem.
Measured both ways rather than asserted. With ee/anything.py staged and a file
importing it, this version exits 1 and the resolution version, run against that
same tree, exits 0.
THE LAST ee REFERENCES. Nine @patch("ee.sqs.SQSProducer.get_sqs_producer") in
test_usage_report.py — string targets, so no import scan sees them; they raise
ModuleNotFoundError only when the test runs. usage_report.py sets producer=None
unconditionally, so the SQS send cannot happen here: the three tests whose
subject was the send are gone, and the five whose subject is the filtering
telemetry keep their assertions with only the dead patch removed.
Also the ones that were never imports at all: LOGIN_METHODS naming
ee.api.authentication backends that are not in AUTHENTICATION_BACKENDS (this
deployment federates through Hanzo IAM and nothing else), five ee receivers in
setup_receivers_baseline.txt, create_ch_migration writing into
"ee/datastore/migrations" — a directory that is not there, so the command
raised FileNotFoundError instead of creating anything — and comments still
pointing readers at ee/ paths for code that now lives here.
DROPPING ("ee", ...) FROM A MIGRATION ALSO DROPPED ITS ORDERING. That dependency
put those migrations after the ee migration that created the roles. Without a
replacement a fresh database fails on `relation "ee_role" does not exist`,
proven by running migrate against one; each now depends on
insights.0002_managed_tables, which is what creates those tables here.
Dockerfile.node named the upstream package it resolves to, which debrand --check
refuses; the override in pnpm-workspace.yaml already says which package it is.