How to tackle intermittent crashes with `error calling Build: interface conversion: interface is nil, not resources.targetPathProvider`

support
1

Hi!

First of all, thank you for hugo! Its a great tool, I like it very much.
We are currently of moving from an old NodeJS version + webpack to hugo’s JS build pipeline. The changes can be found in this PR: Replace Webpack, update to Node 24, Hugo 0.163.3, Cypress 15 by baltpeter · Pull Request #1269 · datenanfragen/website · GitHub

However, we are now currently stuck in the process: Hugo crashes intermittently. You can see me re-triggering the CI-build in the git log commit history with different hugo versions, and the build goes through a couple of times until it finally crashes with an error (4 successful builds with 0.164.0, crash on 5th; 9 builds with 0.165.0, crash on the 10th).

Start building sites …
hugo v0.165.0-76a5e1880ab46688155b02e99bab9be2a6134492+extended linux/amd64 BuildDate=2026-08-12T14:26:28Z VendorInfo=gohugoio

Built in 9633 ms
ERROR error building site: render: [de v1.0.0 guest] failed to render pages: render of "/root/project/content/de/blog/datenloeschung-bei-werbetreibenden/index.md" failed: "/root/project/layouts/_default/baseof.html:102:7": execute of template failed: template: single.html:102:7: executing "single.html" at <partial "scripts" .>: error calling partial: "/root/project/layouts/partials/scripts.html:171:14": execute of template failed: template: _partials/scripts.html:171:14: executing "_partials/scripts.html" at <$batch.Build>: error calling Build: interface conversion: interface is nil, not resources.targetPathProvider
Error: Timed out waiting for: localhost:1314/generator/
at /root/project/node_modules/wait-on/lib/wait-on.js:131:31
at doInnerSub (/root/project/node_modules/wait-on/node_modules/rxjs/dist/cjs/internal/operators/mergeInternals.js:22:31)
at outerNext (/root/project/node_modules/wait-on/node_modules/rxjs/dist/cjs/internal/operators/mergeInternals.js:17:70)
at OperatorSubscriber._this._next (/root/project/node_modules/wait-on/node_modules/rxjs/dist/cjs/internal/operators/OperatorSubscriber.js:33:21)
at Subscriber.next (/root/project/node_modules/wait-on/node_modules/rxjs/dist/cjs/internal/Subscriber.js:51:18)
at AsyncAction.work (/root/project/node_modules/wait-on/node_modules/rxjs/dist/cjs/internal/observable/timer.js:28:28)
at AsyncAction._execute (/root/project/node_modules/wait-on/node_modules/rxjs/dist/cjs/internal/scheduler/AsyncAction.js:79:18)
at AsyncAction.execute (/root/project/node_modules/wait-on/node_modules/rxjs/dist/cjs/internal/scheduler/AsyncAction.js:67:26)
at AsyncScheduler.flush (/root/project/node_modules/wait-on/node_modules/rxjs/dist/cjs/internal/scheduler/AsyncScheduler.js:38:33)
at listOnTimeout (node:internal/timers:605:17)
error Command failed with exit code 1.

(I had to drop the “http” from the “Timed out waiting for:”, as it was detected as a link by discourse.)

Hugo is invoked in this script: website/deploy.sh at webpack-node-staging · datenanfragen/website · GitHub

This seems to be an issue with hugo internals? How could we even start to debug this? I’d appreciate any pointers.

I wish I could provide a reproducable example, but as the problem occurs only sometimes and the changes of that PR are massive I can not at this point.

Blind guesses/points from my side:

  • Can this be a resource consumption issue? Too little resources on the CI machine? (We are currently on the highest tier in our plan at Circle.)
  • @baltpeter, who authored the PR, also saw that error locally before but no way to reproduce it
  • Are there any debug flags / log outputs that could help? :slight_smile:
  • We are using the extended version.
2

without understanding all of your ci script and missing lots of your site code this draws my attention:

               hugo server --baseURL "http://localhost" --disableFastRender --minify & 
                # Wait for server to deploy before continuing (with 1 minute timeout) 
               yarn wait-on tcp:1314 -t 120000 
               yarn wait-on "http://localhost:1314/generator/" -t 240000

looks like you fire up a hugo dev server to run a test suite. (I doubt its just a typo and you actually wanted hugo build).

  • the standard port for the first server running would be 1313. imho you cannot be sure which language will be on 1414 in a multisite setup
  • the dev server is not ment to serve a site. its dev only. hat may cause issues.

for tests i would

  • build the site using hugo build
  • fire up a small real webserver with the results
  • run the test suite

(same if you actually want to generate something ???

a stale or second running hugo server on a reused build agent will also change the port. and also may cause concurrency issues

3

Hi!, thank you for the idea! We tried it and unfortunately the error occurs also with `build`. Replace Webpack, update to Node 24, Hugo 0.163.3, Cypress 15 by baltpeter · Pull Request #1269 · datenanfragen/website · GitHub

We even caught it locally: Replace Webpack, update to Node 24, Hugo 0.163.3, Cypress 15 by baltpeter · Pull Request #1269 · datenanfragen/website · GitHub

4

I seee this place:

working

INFO  postcss: use config file "/root/project/postcss.config.mjs"
INFO  Alias "/de/e.v." contains component with a trailing space or period, problematic on Windows
INFO  Alias "/de/e. v." contains component with a trailing space or period, problematic on Windows
... postcss

### intermediate pages result
INFO  build:  step render substep pages site de outputFormat rss duration 150.691127ms

failing

INFO  postcss: use config file "/root/project/postcss.config.mjs"
INFO  Alias "/de/e.v." contains component with a trailing space or period, problematic on Windows
INFO  Alias "/de/e. v." contains component with a trailing space or period, problematic on Windows

### final pages result
INFO  build:  step render pages 3734 content 203 duration 9.939899333s
INFO  build:  step render deferred count 0 duration 1.696µs

and your error tells there’s “something” undefined in your jsBuild …

=> print all values used in the call, make sure evarything exists, …
=> maybe a partialCached …
=> maybe internal build order problem
=> timing of the postcss npx , …

no idea - if it were mine I would isolate the calls, make sure no one is waiting, just one Hugo … skip postcss, skip jsBuild … if nothing of the above gives a hint.

5

I’d definitely try separating the build from the test server first. Running and then serving the generated files should make it easier to tell whether the crash is in Hugo’s build process or the CI test setup.