Skip to content

test: an earlier spec leaves an open transaction on a pooled BoxLang + SQLite connection #4508

Closed as not planned

Description

@bpamiri

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.

Where it was seen.

  • In JobSchemaSpec (feat(cli): wheels jobs install and jobsAutoCreateTables #4499), in the full BoxLang + SQLite suite, locally and on one full-matrix leg; PR CI passed at the same head.
  • 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.

Activity

  1. added this to the v4.3.0 milestone on Oct 8, 2026
  2. added
    deferredExplicitly deferred past the next release (reason in a comment)
    on Oct 11, 2026
  3. bpamiri commented on Oct 11, 2026

    @bpamiri
    CollaboratorAuthor

    Test-suite reliability item, not a release blocker; targeted for a later release.

  4. bpamiri commented on Oct 14, 2026

    @bpamiri
    CollaboratorAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    deferredExplicitly deferred past the next release (reason in a comment)

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions