PhoenixKitCRM.SchemaOwnerGuardWiringTest fails in setup, so neither of its
two tests ever reaches its assertions.
Reproduced on
3239891 ("Bump version to 0.8.1"), a clean checkout of main with no local
changes.
PGHOST=… PGUSER=… PGPASSWORD=… PGDATABASE=phoenix_kit_crm_test MIX_ENV=test \
mix test test/schema_owner_guard_wiring_test.exs
1) test a real boot through test_helper.exs refuses someone else's marker …
2) test a real boot through test_helper.exs stamps the owner marker …
** (Postgrex.Error) ERROR 55006 (object_in_use)
source database "phoenix_kit_crm_test" is being accessed by other users
There are 8 other sessions using the database.
test/schema_owner_guard_wiring_test.exs:58
2 tests, 2 failures
What is happening
setup clones the suite's own test database to a scratch one
(schema_owner_guard_wiring_test.exs:58-62):
CREATE DATABASE #{scratch_db} TEMPLATE #{@template_db}
with @template_db set to phoenix_kit_crm_test. Postgres refuses to use a
database as a TEMPLATE while any other session is connected to it, and the
running suite's own connection pool holds exactly such sessions — the eight the
error reports. So the clone fails whenever the suite is running, which is the
only circumstance in which this test runs.
The comment above that block explains why cloning was chosen over creating an
empty scratch database (an empty one would drag the full core migration chain
through boot), so the intent is clear; it is the choice of @template_db that
collides with the pool.
Why this may have gone unnoticed
The failure is in setup, so both tests report as failures rather than as
assertion mismatches, and the module's other tests — the ones that call
check!/1 and stamp!/1 directly — pass. That combination reads like coverage
of the wiring while the wiring itself is never exercised, which is precisely
what this test exists to prevent.
Direction, not a prescription
Two shapes seem available, and which is right is your call: clone from a
separate, already-migrated template database that nothing connects to, or take
the pool down for the duration of the clone. We have not implemented either —
this is a report, not a patch.
PhoenixKitCRM.SchemaOwnerGuardWiringTestfails insetup, so neither of itstwo tests ever reaches its assertions.
Reproduced on
3239891("Bump version to 0.8.1"), a clean checkout ofmainwith no localchanges.
What is happening
setupclones the suite's own test database to a scratch one(
schema_owner_guard_wiring_test.exs:58-62):with
@template_dbset tophoenix_kit_crm_test. Postgres refuses to use adatabase as a
TEMPLATEwhile any other session is connected to it, and therunning suite's own connection pool holds exactly such sessions — the eight the
error reports. So the clone fails whenever the suite is running, which is the
only circumstance in which this test runs.
The comment above that block explains why cloning was chosen over creating an
empty scratch database (an empty one would drag the full core migration chain
through boot), so the intent is clear; it is the choice of
@template_dbthatcollides with the pool.
Why this may have gone unnoticed
The failure is in
setup, so both tests report as failures rather than asassertion mismatches, and the module's other tests — the ones that call
check!/1andstamp!/1directly — pass. That combination reads like coverageof the wiring while the wiring itself is never exercised, which is precisely
what this test exists to prevent.
Direction, not a prescription
Two shapes seem available, and which is right is your call: clone from a
separate, already-migrated template database that nothing connects to, or take
the pool down for the duration of the clone. We have not implemented either —
this is a report, not a patch.