Problem
workspace_lease_sweep_test.py's fake session honours a SQL LIMIT so that
test_a_backlog_of_executed_proposals_does_not_hide_the_unexecuted_one can actually observe the
defect it was written for (#16818, PR #17725). It reads the limit off SQLAlchemy internals:
limit = getattr(statement, "_limit", None)
if limit is None:
limit_clause = getattr(statement, "_limit_clause", None)
limit = getattr(limit_clause, "value", None)
Both are private attributes. If SQLAlchemy renames or restructures them, every getattr returns
None, the fake silently stops applying limits, and the regression test passes whether or not the
bug is present — back to being unfailable.
The failure arrives through a dependency bump rather than a code change, so nothing in the diff that
breaks it will look like it touches this.
Why this is worth its own issue
This is the same lesson one layer down from the one that produced the test. The original test could
not fail because the fake ignored LIMIT; teaching it to read LIMIT fixed that and created a new
unverified assumption — that the reading still works. A harness that silently degrades is
indistinguishable from one that works, which is the property the whole #16818 review was about.
Acceptance criteria
Note on scope
Two lines of assertion. The reason it is filed rather than slipped into #17725 is that #17725 is
queued and reviewed; this is a new test for a test harness, not a fix to the change under review.
Related
Follow-up to #16818, found by review on PR #17725. Does not block that PR.
Problem
workspace_lease_sweep_test.py's fake session honours a SQLLIMITso thattest_a_backlog_of_executed_proposals_does_not_hide_the_unexecuted_onecan actually observe thedefect it was written for (#16818, PR #17725). It reads the limit off SQLAlchemy internals:
Both are private attributes. If SQLAlchemy renames or restructures them, every
getattrreturnsNone, the fake silently stops applying limits, and the regression test passes whether or not thebug is present — back to being unfailable.
The failure arrives through a dependency bump rather than a code change, so nothing in the diff that
breaks it will look like it touches this.
Why this is worth its own issue
This is the same lesson one layer down from the one that produced the test. The original test could
not fail because the fake ignored
LIMIT; teaching it to readLIMITfixed that and created a newunverified assumption — that the reading still works. A harness that silently degrades is
indistinguishable from one that works, which is the property the whole #16818 review was about.
Acceptance criteria
select(...).limit(1)against two rows andasserts exactly one comes back.
getattrpaths returnNone— i.e. it tests the fake, not SQLAlchemy.Note on scope
Two lines of assertion. The reason it is filed rather than slipped into #17725 is that #17725 is
queued and reviewed; this is a new test for a test harness, not a fix to the change under review.
Related
Follow-up to #16818, found by review on PR #17725. Does not block that PR.