Fix functions.bxs/layout.bxm include failures via registered mappings - #126
Fix functions.bxs/layout.bxm include failures via registered mappings#126lmajano wants to merge 3 commits into
Conversation
Roughly a third of the "Publish Docs" theme-gallery matrix jobs (fresh JVM per job) were hitting functions.bxs at [...] failed to load: The template path [...] could not be found on the very first include the whole build performs, immediately after fileExists() on that exact path had just confirmed it was there - blocking assemble-and-deploy (needs: build) every time, since a different subset of themes crashed on each run. That shape - transient, only on the first include of the run, on a path a moment-old existence check already verified - points to a cold-start race in BoxLang's own template resolver rather than a real missing file. load() now retries up to twice more (150ms/300ms backoff) when it hits that specific message and a fresh fileExists() recheck still confirms the file exists; any other failure, including a real syntax error in a project's own functions.bxs, still throws immediately on the first attempt.
The previous commit treated the symptom as a timing race and retried the include. It isn't a race: BoxLang's include statement never resolves a bare OS absolute path against the filesystem at all - an absolute-looking path gets coerced against registered mappings/webroot instead, so include functionsPath (and ThemeRenderer.bx's identical include arguments.themeDir & "/layout.bxm") were simply an unsupported way to reach an arbitrary, runtime-computed directory, regardless of how many times it's retried. Both now call getBoxRuntime().getConfiguration().registerMapping() to register a mapping for the target directory, then include through that mapping-prefixed path - the actual supported mechanism for this. Fixed ThemeRenderer.bx's layout.bxm include too, even though it hasn't been observed failing yet - it's the identical pattern, and every failing build so far aborted at functionsLoader.load() before any page ever reached this code path, so absence of evidence there isn't evidence of absence.
|
Update: the "cold-start race" theory in this PR's description was wrong. Per @lmajano: BoxLang's Pushed a follow-up commit that replaces the retry loop with the actual fix: both now call Generated by Claude Code |
lmajano
changed the title
|
Generated by Claude Code |
tests.yml's test suite was intermittently failing before a single spec ran, with ClassNotFoundBoxLangException on TestBox's own BoxLangRunner.bx - blocking this PR's own CI (and any other PR's) independently of the registerMapping fix above. Root cause turned out to be a real TestBox bug, not a BoxLang engine issue: server.cli.parsed.positionals leaks the runner's own invocation path as argv[0] on current engine builds, and BoxLangRunner.bx's naive `positional[1]` grab misread that as a user-supplied bundle argument whenever none was actually given. Fixed upstream in Ortus-Solutions/TestBox#201 (reproduced and verified locally there). Pin id=testbox to id=testbox@be so CI picks up that fix from the bleeding-edge channel now, rather than waiting on a tagged stable TestBox release. Revert to the unpinned id=testbox once one ships it.
|
Update on the recurring Pushed a commit pinning Generated by Claude Code |
|
Progress, but not there yet: Sent this back to the same TestBox investigation thread (same repo, same context) to fix. Keeping this PR watched until it's resolved. Generated by Claude Code |
2 participants
Summary
PR #125 fixed
pages.yml's deploy trigger, but the very nextPublish Docsrun (triggered automatically by that merge) still failed to deploy - 3-4 of the 10 theme matrix jobs crashed each time, with a different subset of themes failing on each run:assemble-and-deployhasneeds: build, so any matrix job failing skips the deploy entirely - this is the reason the site still wasn't publishing after #125.Root cause
BoxLang's
includestatement never resolves a bare OS absolute filesystem path against the real filesystem - an absolute-looking path is coerced against registered mappings/webroot instead.FunctionsLoader.bx'sload()calledinclude functionsPathwith a real,fileExists()-confirmed absolute path, which is simply an unsupported way to reach an arbitrary, runtime-computed directory - not a timing race, as an earlier version of this PR assumed. It went unnoticed until now because this repo only recently started shipping a real, non-emptydocs/functions.bxs.ThemeRenderer.bx'sinclude arguments.themeDir & "/layout.bxm"has the identical pattern - it just hasn't been observed failing yet, since every failing build so far aborted atfunctionsLoader.load()(the very firstincludethe whole build performs) before any page ever reached that code path.Fix
Both now call
getBoxRuntime().getConfiguration().registerMapping()to register a mapping for the target directory, thenincludethrough that mapping-prefixed path instead - the actual supported mechanism for including a runtime-computed absolute path. Any other failure (e.g. a real syntax error in a project's ownfunctions.bxs) still throws immediately, unchanged from before.Test plan
FunctionsLoaderSpec.bx/ThemeRendererSpec.bxsuites still passPublish Docsrun has all 10 theme builds succeed andassemble-and-deployactually runs/next/for work in progress)