You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test: an earlier spec leaves an open transaction on a pooled BoxLang + SQLite connection #4508
What happens. In the full core suite on BoxLang + SQLite, a spec can drop a table and still see it through a later query on another pooled connection:
DROP TABLE wheels_jobs succeeds;
a catalog check (sqlite_master) right after it reports the table gone;
yet the next SELECT ... FROM wheels_jobs (from framework code, on another pooled connection) still finds the table.
It shows up only in the full suite. Running directory=wheels.tests.specs.jobs alone passed four times in a row.
Likely cause. An earlier spec leaves a pooled connection inside an uncommitted transaction (autocommit off). The SQLite test datasource uses the default rollback journal, not WAL. So a later DROP that lands on that connection runs inside the open transaction:
that connection sees the table gone;
other connections still see it until the transaction ends.
This is a suite-isolation leak, not a product bug. It makes "drop, then expect missing" specs order-dependent on BoxLang + SQLite.
The affected spec now no longer drops anything: it simulates the failure with a datasource that doesn't exist.
The schema specs' drop helpers now confirm the drop through the catalog and fail with the DROP's error instead of swallowing it.
Other drop-then-expect-missing specs (for example JobSchemaSpec's "creates nothing with jobsAutoCreateTables = false") can still hit it, depending on order.
To do.
Bisect which earlier spec (or spec directory) leaves the open transaction on BoxLang + SQLite. Candidates include specs that open transaction action = "begin" themselves, or that leave one open on an error path; the database/ and model/ directories run before jobs/.
Fix the leak at its source (commit or roll back in that spec's afterEach, or end any open transaction in the test runner between bundles), rather than making each later spec defensive.
Acceptance criteria.
The leaking spec is identified and fixed.
A drop-then-expect-missing spec passes in the full BoxLang + SQLite suite regardless of order.
This doesn't reproduce on current develop (cb023eb):
Full suite: the core suite on BoxLang + SQLite passes, 7311 pass, 0 fail, 0 error.
Detector: I ran an extra spec in the same container before the full suite and again right after it, in the same server so the connection pool persists. It creates and drops a probe table eight times, and after each drop checks sqlite_master from eight separate queries. A pooled connection left inside an open transaction would show up as the dropped table still being visible, or as a lock/busy error.
Before the full suite: clean.
After the full suite: clean. 0 stale reads, 0 errors.
Since #4499, the drop-then-expect-missing specs this was seen in no longer drop real tables, or they confirm the drop through the catalog. Closing as not reproducible; it can be reopened if a full BoxLang + SQLite run shows the symptom again.
Activity
bpamiri commentedon Oct 11, 2026
Test-suite reliability item, not a release blocker; targeted for a later release.
bpamiri commentedon Oct 14, 2026
This doesn't reproduce on current
develop(cb023eb):sqlite_masterfrom eight separate queries. A pooled connection left inside an open transaction would show up as the dropped table still being visible, or as a lock/busy error.Since #4499, the drop-then-expect-missing specs this was seen in no longer drop real tables, or they confirm the drop through the catalog. Closing as not reproducible; it can be reopened if a full BoxLang + SQLite run shows the symptom again.