BoxLang: getStatusCode() throws — adapter getResponse() override breaks Base.cfc lookup

[bpamiri]

Describe the bug

On BoxLang, every call to engineAdapter.getStatusCode() (or anything that reaches the status code through Global.cfc::$getStatusCode()) throws:

Error getting method [getStatus] for class [ortus.boxlang.servlet.BoxPageContext]

This causes 600 test errors across 10 bundles × 5 databases in the latest compat-matrix run on develop — by far the single largest source of BoxLang errors. Fixing this alone reduces #2649's BoxLang error count from ~125/DB to ~25/DB.

Evidence

Compat-matrix run #25837380625 (2026-05-13, develop). Bundles affected (count = occurrences across DBs):

Count	Bundle
215	wheels.tests.specs.controller.renderingSpec
140	wheels.tests.specs.controller.csrf.cookieSpec
140	wheels.tests.specs.controller.csrf.sessionSpec
40	wheels.tests.specs.controller.sseSpec
25	wheels.tests.specs.controller.miscellaneousSpec
15	wheels.tests.specs.controller.verifiesSpec
15	wheels.tests.specs.global.publicSpec
5	wheels.tests.specs.controller.cachingSpec
5	wheels.tests.specs.controller.redirectionSpec
5	wheels.tests.specs.engineAdapterSpec

All on cockroachdb, mysql, oracle, postgres, sqlite. (Lucee 6 / Adobe pass these specs cleanly.)

To Reproduce

1. Hit /wheels/core/tests?db=sqlite&format=json&directory=tests.specs.engineAdapterSpec on the BoxLang engine container.
2. The spec Engine Adapter :: returns a status code as numeric errors with the message above.

Expected behavior

engineAdapter.getStatusCode() returns the current HTTP response status as a numeric (200 by default).

Root cause

vendor/wheels/engineAdapters/BoxLang/BoxLangAdapter.cfc:18-20 overrides getResponse() to return GetPageContext() directly:

public any function getResponse() {
    return GetPageContext();
}

This override exists for getContentType()'s benefit (BoxLang reads Content-Type off the request, not the response, so the override lets getContentType() call local.response.getRequest().getHeader(...)).

But Base.cfc:75-76 then does:

public numeric function getStatusCode() {
    return getResponse().getStatus();
}

On BoxLang that becomes GetPageContext().getStatus() — and ortus.boxlang.servlet.BoxPageContext does not expose a getStatus() method (only the wrapped HttpServletResponse does).

Suggested fix shape

Add a single getStatusCode() override to BoxLangAdapter.cfc that goes through the actual response object:

/**
 * BoxLang's PageContext doesn't expose getStatus() directly.
 * Reach the underlying HttpServletResponse to read it.
 */
public numeric function getStatusCode() {
    return GetPageContext().getResponse().getStatus();
}

5-line change. A failing-spec target already exists: engineAdapterSpec :: returns a status code as numeric.

Additional context

• Part of the Core test suite has high failure/error rate on BoxLang (35 failures, 125 errors, 3526 passing) #2649 decomposition (Tier 1, headline finding). Identified by clustering BoxLang error messages from the matrix run; 86% of all BoxLang errors share this single normalized message.
• Adapter-pattern hazard worth flagging: overriding getResponse() in a subclass is a load-bearing change. Every Base.cfc method that calls getResponse() is now BoxLang-untested. A one-time audit (grep getResponse() Base.cfc) and an override-or-explicit-deletion decision for each caller would prevent the next bug of this shape. The current state is "one base method overridden, three base methods quietly broken."
• Lucee/Adobe are unaffected — they don't override getResponse(), so Base.cfc::getStatusCode() resolves against their respective HttpServletResponse directly.

Related: #2649

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

controller — see .ai/wheels/controllers/ for canonical patterns. The fault sits in the engine-adapter layer that the controller dispatch / rendering pipeline calls into. .ai/wheels/cross-engine-compatibility.md is also directly relevant since the override-shape interaction with Base.cfc is the proximate cause.

Fix sketch

Add a getStatusCode() override to vendor/wheels/engineAdapters/BoxLang/BoxLangAdapter.cfc that reaches the underlying HttpServletResponse (GetPageContext().getResponse().getStatus()), as proposed in the issue body. The failing target spec already exists at vendor/wheels/tests/specs/engineAdapterSpec.cfc (returns a status code as numeric); the fix should make that pass on BoxLang while leaving Lucee/Adobe behavior unchanged (they don't override getResponse(), so Base.cfc::getStatusCode() continues to resolve correctly). The reporter's "adapter-pattern hazard" call-out (audit every getResponse() caller in Base.cfc for analogous breakage) is worth surfacing to propose-fix as scope to consider.

Confidence: medium

The report is exceptionally clear (root cause, exact target file, fix shape, failing spec already exists) and would otherwise rate high, but the auto-downgrade rule for cross-engine concerns (Lucee/Adobe behavior diverges from BoxLang here) caps it at medium.

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

[wheels-bot]

Wheels Bot — Fix proposed

Draft PR: #2666

Spec: vendor/wheels/tests/specs/engineAdapterSpec.cfc — added returns a valid HTTP status code without throwing on any engine assertion (regression context for the existing returns a status code as numeric test) — currently fails on BoxLang, passes on Lucee/Adobe, will pass on every engine after this PR.

Implementation: vendor/wheels/engineAdapters/BoxLang/BoxLangAdapter.cfc — added a 5-line getStatusCode() override that reaches the underlying HttpServletResponse via GetPageContext().getResponse().getStatus() instead of inheriting Base.cfc::getStatusCode() (which resolves to PageContext.getStatus() under the adapter's getResponse() → PageContext override).

Local Lucee 7 + SQLite run: 3520 pass / 0 fail / 0 error / 16 skipped (same totals as develop pre-change — no regressions). The BoxLang-side failure can only be reproduced on the BoxLang engine container; the CI compat-matrix will exercise it on the PR.

A human review is required before merge. Reviewer A and Reviewer B will weigh in shortly. Doc updates (MDX guides, .ai/wheels/, CLAUDE.md) are handled separately by bot-update-docs.yml.

The triage and the issue body both flagged a broader adapter-pattern hazard — every Base.cfc method that calls getResponse() is now BoxLang-untested because the BoxLang adapter's getResponse() returns a PageContext rather than a response object. The two other callers (getResponseWriter, getContentType) need an audit. getContentType is already overridden; getResponseWriter is currently unverified on BoxLang. That audit is intentionally out of scope for this PR (minimal change for the failing-spec target) and called out in the PR body for a follow-up.