BoxLang: Internal Wheels routes fail with `Function [$blockInProduction] not found`

[zainforbjs]

Describe the bug
When running Wheels on BoxLang, all internal Wheels pages fail with the following error:

Application Error
Function [$blockInProduction] not found

The error originates from:
/vendor/wheels/Public.cfc: line 87

As a result, none of the internal Wheels routes (such as Routes, Migrations, Packages, Guides, Tests, etc.) can be accessed.

To Reproduce
Steps to reproduce the behavior:

1. Run the Wheels repository or a Wheels application using BoxLang.
2. Navigate to any internal Wheels page, such as:
   /wheels/info
/wheels/routes
/wheels/packages
/wheels/guides
3. Observe the application error.

Expected behavior
All internal Wheels routes should render successfully on BoxLang.

Screenshots

Desktop:

• OS: Any
• CFML Engine: Boxlang

Additional context
The error occurs in vendor/wheels/Public.cfc, which suggests the $blockInProduction() method is not being integrated or resolved correctly in BoxLang.

Possible causes include:

• BoxLang handling of private/public methods differently
• Method name resolution differences for methods prefixed with $

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

controller — see .ai/wheels/cross-engine-compatibility.md and .ai/wheels/controllers/ for canonical patterns. The Public.cfc acts as the controller for internal Wheels GUI routes, and dispatch to it is mediated by the engine adapter.

Fix sketch

The error surfaces at vendor/wheels/Public.cfc:87 ($blockInProduction()) but the root cause is in vendor/wheels/engineAdapters/BoxLang/BoxLangAdapter.cfc:189-192. The BoxLang adapter dispatches controller actions by extracting a method reference and calling it standalone:

public void function invokeMethod(required any object, required string methodName) {
    local.method = arguments.object[arguments.methodName];
    local.method();
}

When BoxLang invokes local.method() this way, the component context (this / variables scope) of the originating Public.cfc instance appears to be lost, so the in-component call to $blockInProduction() from inside info() / routes() / etc. can't resolve. The fix likely replaces the function-reference dance with a context-preserving call — either Invoke(arguments.object, arguments.methodName) or arguments.object[arguments.methodName]() invoked directly without the intermediate local.method variable — so the receiver is preserved. The Lucee/Adobe path in vendor/wheels/engineAdapters/Base.cfc:237 should be left alone; only the BoxLang override needs to change. A spec belongs in vendor/wheels/tests/specs/security/PublicComponentProductionSpec.cfc (or a new BoxLang-tagged spec under vendor/wheels/tests/specs/dispatch/) covering each internal route on BoxLang.

Confidence: medium

Auto-downgraded from high: the issue is clearly described and the fix is mechanical, but a cross-engine concern (BoxLang-only method-dispatch semantics) is in play, which forces medium per the triage rules.

<!-- wheels-bot:triage:2646 -->
<!-- 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 (vendor/wheels/engineAdapters/BoxLang/BoxLangAdapter.cfc — cross-engine method-dispatch semantics) and the bot's safety net requires a human in the loop before any code is written.

The triage comment already identified this as a cross-engine concern and auto-downgraded confidence to medium. Two further factors made the bot reluctant to ship a one-shot fix:

1. The local test runner (bash tools/test-local.sh) executes on Lucee 7, so a BoxLang-only behavioral change cannot be verified end-to-end here without bringing up the BoxLang Docker container — and even then, the failure mode is in HTTP-dispatched controller actions, not a unit-isolatable call site.
2. The current BoxLang override was deliberately written to avoid Invoke() (see the comment at vendor/wheels/engineAdapters/Base.cfc:230-232). The triage's two suggested replacements (Invoke() back-to-Base vs. arguments.object[arguments.methodName]() inline) have different trade-offs on BoxLang that need a human who can run BoxLang to pick the right one.

A human should:

• Bring up the BoxLang container (tools/test-matrix.sh boxlang sqlite) and reproduce by hitting /wheels/info or /wheels/routes.
• Pick between the two candidate forms, or a third (e.g., calling via invoke() with argumentCollection={} if BoxLang now supports it) based on what actually preserves the component's this scope.
• Add a regression spec under vendor/wheels/tests/specs/dispatch/ that the BoxLang container in CI will actually execute.