Repository navigation
fix(ci): integration job queries the right place (#45) - #61
Merged
amar-python merged 2 commits intoOct 25, 2026
Merged
Conversation
…ght place (#45) Two independent causes, both reproduced locally against PostgreSQL 16 with the job's exact steps: 1. Tier E bound the schema name with `psql --set ... -c`. psql never interpolates :'var' inside -c, so every query was a syntax error, which _column_signature turned into an empty result: "0 tables". The query now goes on stdin, and a failed query is reported as a query error instead of an empty schema. Three negative controls; two of them fail against the old code. 2. The job sets PGDATABASE=postgres, and api/config.py reads PGDATABASE, so the API looked for te_dev in the wrong database. The full-suite step now sets PGDATABASE=te_mgmt_dev. With Tier E working it found one real difference: dev has test_run_results, created by the Tier S SQL test harness. It is listed in the Tier E expectation file as ignored, with the reason, rather than filtered silently. Local replay: evals P/I/S/E 26/26, test_report --strict 239/239, 0 skipped; make lint clean. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AYM3RR8Fmw2pwqFfnJhAo6
Replaces the ignore_tables exception from the previous commit, per review: Tier E should need no exceptions. run_all_tests.sql now creates schema te_test_harness and puts it first on search_path, so test_framework.sql's unqualified CREATEs (test_run_results, assert_*, report_*) land there instead of in te_dev. T&E tables still resolve from the env schema, and the suites already address it through te.schema_name. The four report calls are qualified with te_test_harness. Tier S caught the first attempt, which left the report calls qualified with the env schema. Local replay on PostgreSQL 16: te_dev holds exactly 12 tables; evals P/I/S/E 26/26, 0 skipped; test_report --strict 238/238, 0 skipped; make lint clean. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AYM3RR8Fmw2pwqFfnJhAo6
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
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.
Fixes #45. Targets
gap-remediation-2026-09(PR #44), so merging this turns #44's integration check green.Root causes (both reproduced locally with the job's exact steps, PostgreSQL 16)
_column_signaturepassed--set=sch=...with-c. psql does not interpolate:'sch'inside-c, so the query was a syntax error, and the function returned{}, which Tier E reported as "0 tables". The query now goes on stdin, and a failed query is reported as a query error.PGDATABASE=postgres;api/config.pyreadsPGDATABASE; the schema lives inte_mgmt_dev. The full-suite step now setsPGDATABASE=te_mgmt_dev.The original hypothesis in #45 (one root cause: deploys landing in the wrong database) was wrong. Deploys were correct;
te_core_schema.sqldoes\c :"db_name".Harness isolation (second commit, per review)
Once Tier E worked, it found a real difference:
te_devheldtest_run_results, created by the Tier S SQL harness. Rather than anignore_tablesexception (first commit, now reverted),run_all_tests.sqlcreates schemate_test_harnessand puts it first onsearch_path, so the harness's tables and functions never land in the schema under test.te_devnow holds exactly the 12 deployed tables.Existing local databases still hold the old harness objects in
te_devfrom earlier runs. On a machine that has run the SQL tests before, Tier E will reporttest_run_resultsas drift until it is dropped fromte_dev.Evidence (local replay, not CI)
scripts/test_report.py --strictwithPGDATABASE=te_mgmt_dev: 238 collected, 238 passed, 0 failed, 0 skippedmake lint: cleanrunner.py; the empty-schema control passes against both, as intendedte_devafter a full run: 12 tables; harness objects inte_test_harnessCI on this PR is the independent run.
https://claude.ai/code/session_01AYM3RR8Fmw2pwqFfnJhAo6
Generated by Claude Code