Found delta-checking commit 9202f628c7 on PR #6049. The commit is correct. This is about what pins it.
What the commit does
AGENTA_TEST_NO_DATABASE lets a deployment declare that it publishes no database, so the integration layer skips database-bound cases by name instead of erroring. The declaration is honoured in two places, and the commit body says why both are needed:
Honoured at both ways in, not one: the autouse guard, and require_core_uri, which the grant-rekey file calls directly. Declaring it at the guard alone left 15 of the 111 still erroring.
So the second honouring point, the two lines inside require_core_uri in api/oss/tests/pytest/utils/postgres.py, is load-bearing for 15 cases.
What pins it
The commit adds three unit cases to api/oss/tests/pytest/unit/utils/test_integration_postgres_address.py. All three go through guard_the_deployment_under_test, which is the first honouring point. None of them reaches the second.
Verified by mutation rather than by reading. Deleting only the two lines inside require_core_uri:
- if declares_no_database():
- skip_for_declared_absence()
- the target file:
31 passed, exit 0
- the whole unit layer:
5036 passed, 176 skipped, exit 0
The line is genuinely reachable, so this is not a mutation that failed to execute. Instrumenting the top of require_core_uri shows it runs three times during that file. The branch simply has nothing asserting about it.
Why it is worth a case
The first honouring point is covered. The second is covered only by running the integration layer against a deployment whose database is unreachable, which is the Railway job and nothing else. A PR that removed those two lines would go green on every check a contributor sees, and the regression would surface as 15 errors in a job that runs later and for other reasons.
Suggested fix
The existing parametrised case is three lines from covering it. Alongside test_a_declared_absence_skips_by_name_rather_than_failing, assert the same about the direct caller:
@pytest.mark.parametrize("declared", ["1", "true", "yes", "anything"])
def test_a_declared_absence_skips_the_direct_caller_too(monkeypatch, declared):
"""The grant-rekey file asks for the database directly, not through the guard."""
monkeypatch.setenv("AGENTA_TEST_NO_DATABASE", declared)
monkeypatch.setattr(helper, "_connectable", lambda _uri: False)
with pytest.raises(pytest.skip.Exception) as outcome:
helper.require_core_uri()
assert "declares no database access" in str(outcome.value)Mutation-check it by deleting the two lines and watching those four cases fail.
Found delta-checking commit
9202f628c7on PR #6049. The commit is correct. This is about what pins it.What the commit does
AGENTA_TEST_NO_DATABASElets a deployment declare that it publishes no database, so the integration layer skips database-bound cases by name instead of erroring. The declaration is honoured in two places, and the commit body says why both are needed:So the second honouring point, the two lines inside
require_core_uriinapi/oss/tests/pytest/utils/postgres.py, is load-bearing for 15 cases.What pins it
The commit adds three unit cases to
api/oss/tests/pytest/unit/utils/test_integration_postgres_address.py. All three go throughguard_the_deployment_under_test, which is the first honouring point. None of them reaches the second.Verified by mutation rather than by reading. Deleting only the two lines inside
require_core_uri:31 passed, exit 05036 passed, 176 skipped, exit 0The line is genuinely reachable, so this is not a mutation that failed to execute. Instrumenting the top of
require_core_urishows it runs three times during that file. The branch simply has nothing asserting about it.Why it is worth a case
The first honouring point is covered. The second is covered only by running the integration layer against a deployment whose database is unreachable, which is the Railway job and nothing else. A PR that removed those two lines would go green on every check a contributor sees, and the regression would surface as 15 errors in a job that runs later and for other reasons.
Suggested fix
The existing parametrised case is three lines from covering it. Alongside
test_a_declared_absence_skips_by_name_rather_than_failing, assert the same about the direct caller:Mutation-check it by deleting the two lines and watching those four cases fail.