BoxLang: lockingSpec doesn't release advisory lock when callback throws

[bpamiri]

Describe the bug

On BoxLang, the lockingSpec :: releases lock even when callback throws an exception test fails on MySQL, Postgres, and SQLite with:

Expected [false] to be true

The spec verifies that after the locking callback throws, the lock is released. Lucee 6 and Lucee 7 pass this spec on the same three DBs — only BoxLang fails. Strongly suggests a BoxLang-specific try/finally semantic difference: the unlock path isn't executing when the callback raises.

Failing spec (BoxLang only)

wheels.model.lockingSpec :: releases lock even when callback throws an exception

Fails on: BoxLang × MySQL, BoxLang × Postgres, BoxLang × SQLite (3 DBs, same spec, same engine).
Passes on: Lucee 6 / Lucee 7 across all DBs.

Reproduction

tools/test-matrix.sh boxlang mysql
# or
curl 'http://localhost:60001/wheels/core/tests?db=mysql&format=json&directory=tests.specs.model'

Suspected cause

The locking implementation is likely structured as:

try {
    acquireLock(...);
    callback();
} finally {
    releaseLock(...);
}

Or possibly using cflock / a CFC wrapper. BoxLang may not be running the finally block when the callback throws — or the implementation uses an exception-handling shape (e.g., try/catch without re-throw, or a CFC-method-level handler) that doesn't behave identically on BoxLang.

Locate the locking impl that backs this spec — probably vendor/wheels/model/locking.cfc (or similar) — and verify the cleanup path runs on BoxLang under thrown exception. May need restructuring to use plain try/finally if it currently uses something more exotic.

Evidence

Compat-matrix run 25978222394 (develop, 2026-05-17):

• boxlang/mysql: 1 fail (this spec)
• boxlang/postgres: 1 fail (this spec)
• boxlang/sqlite: 1 fail (this spec)
• lucee6/<same DBs>: passes
• lucee7/<same DBs>: passes

Expected behavior

Lock is released after callback throws — spec passes on BoxLang on the same DBs that Lucee passes on.

Related

• Parent: Core test suite has high failure/error rate on BoxLang (35 failures, 125 errors, 3526 passing) #2649 (BoxLang compat rollup)
• Adjacent: test: lockingSpec advisory-lock + transaction tests need engine guards for H2 and SQL Server #2665 (engine guards for H2 / SQL Server) — different fix shape

Desktop

• CFML Engine: BoxLang

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

model — see .ai/wheels/cross-engine-compatibility.md for BoxLang-specific runtime semantics. The implementation backing the failing spec lives in vendor/wheels/model/locking.cfc (52 lines, small surface).

Fix sketch

The failing spec — wheels.model.lockingSpec :: releases lock even when callback throws an exception — asserts that the unlock path runs after the callback raises. Lucee 6/7 pass on the same DBs (MySQL/Postgres/SQLite); only BoxLang fails, so this is a BoxLang try/finally (or equivalent) semantic gap rather than a DB issue. Inspect vendor/wheels/model/locking.cfc to confirm the cleanup is structured as a plain try { ... } finally { releaseLock(...); } block (or cffinally) and that the releaseLock call doesn't get short-circuited by the rethrow. If the code uses a CFC-method-level handler, try/catch without rethrow, or any exotic exception-handling shape, restructure to a flat try/finally and ensure the lock is released before the exception propagates. Re-run tools/test-matrix.sh boxlang sqlite (fastest) to confirm.

Confidence: medium

Issue is unambiguous and the fix target is one small file, but cross-engine concern (BoxLang vs Lucee try/finally semantics) triggers the auto-downgrade rule.

<!-- wheels-bot:triage:2744 -->
<!-- wheels-bot:triage-class:bug -->
<!-- wheels-bot:triage-confidence:medium -->

[wheels-bot]

Wheels Bot — Fix on hold for human review

The proposed fix touches a sensitive area (BoxLang cross-engine try/finally semantics in vendor/wheels/model/locking.cfc) and the bot's safety net requires a human in the loop before any code is written.

The triage comment explicitly flagged the cross-engine concern. The fix may need engine-specific reasoning about exception propagation through try/finally (no catch), which is exactly the class of change the auto-downgrade rule covers.