Deferred template crashes server

[jloh]

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.128.2-de36c1a95d28595d8243fd8b891665b069ed0850 darwin/arm64 BuildDate=2024-07-04T08:13:25Z VendorInfo=gohugoio

I normally use the extended version but currently seem to just have the standard version installed.

Does this issue reproduce with the latest release?

Yes

---

I'm currently trying the new deferred templates since I've historically found when changing my CSS classes Hugo can sometimes generate an outdated Tailwind build. Every now and then though my dev server panics and crashes with the below error:

Change detected, rebuilding site (#1).
2024-07-12 21:53:03.587 +1000
Source changed /posts/geojs-2023.md
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Total in 548 ms
panic: deferred execution with id "__hdeferred/65688a805435c475b81b9d3dea03e9d4_9c70933aff6b2a6d08c687a6cbb6b765__d=" not found

goroutine 9989 [running]:
github.com/gohugoio/hugo/hugolib.(*Site).executeDeferredTemplates.func1.1(0x140096ce361?, {0x1400a0a0a80, 0x51}, 0x140009f5b00, 0x14000b87e78, 0x14000b87e90, 0x361, 0x3b2, 0x14000b87e37)
        /root/project/hugo/hugolib/hugo_sites_build.go:473 +0x3b4
github.com/gohugoio/hugo/hugolib.(*Site).executeDeferredTemplates.func1({0x1400b9430a9, 0xb})
        /root/project/hugo/hugolib/hugo_sites_build.go:506 +0x1dc
github.com/gohugoio/hugo/hugolib.(*Site).executeDeferredTemplates.func2({0x140011e7728?, 0x140011e7708?}, {0x1400b9430a9?, 0x0?})
        /root/project/hugo/hugolib/hugo_sites_build.go:523 +0x30
github.com/gohugoio/hugo/common/rungroup.Run[...].func1()
        /root/project/hugo/common/rungroup/rungroup.go:64 +0xb4
golang.org/x/sync/errgroup.(*Group).Go.func1()
        /root/project/gomodcache/golang.org/x/[email protected]/errgroup/errgroup.go:78 +0x58
created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 9896
        /root/project/gomodcache/golang.org/x/[email protected]/errgroup/errgroup.go:75 +0x98

This is the result of me editing a post on the site.

My deferred template looks like this:

{{ with (templates.Defer (dict "key" "global")) }}
	{{- $options := (dict "inlineImports" true ) -}}
	{{- $tailwind := resources.Get "css/main.css" | resources.PostCSS $options -}}
	{{- $tailwind = $tailwind | resources.Fingerprint "sha512" | resources.PostProcess -}}
	<link rel="stylesheet" href="{{ $tailwind.RelPermalink }}" />
{{ end }}

Which is included in my baseof.html via {{ partialCached "head/css" . }}. I've tried moving it to just baseof.html but it crashes randomly doing that as well.

Anything I can do to help debug?

[bep]

Anything I can do to help debug?

Not really. I understand the what, just not the how. This feature is fairly straight forward for regular hugo builds, but I guess it needs some better testing on the server/rebuild side.

{{- $tailwind = $tailwind | resources.Fingerprint "sha512" | resources.PostProcess -}}

I guess the main reason I have not seen this in my setups is that I have constructs similar to this:

https://github.com/bep/hugo-testing-tailwindcss-v4/blob/83bb55e02b73b58cde989a705c653aeb9e57c0b2/postcss-cli-defer/layouts/_default/baseof.html#L17

That is, in your setup, the defer block will change whenever the stylesheet/fingerprint changes, which (in my head) has several drawbacks.

[jloh]

My reasoning for using defer was I found using Tailwind's purging resulted in weird builds during development where it often would require a full restart of the dev server to get classes that were previously missing.

Changing my defer template over to the one you link above (ie no fingerprinting) seems to result in a more stable build though!

Just realised this is because it stopped using resources.PostProcess so I think doesn't defer?

I've never had problems with Hugo generating CSS on a live build (ie just hugo command), its purely been a problem for me with the development server interestingly.

[bep]

{{- $tailwind = $tailwind | resources.Fingerprint "sha512" | resources.PostProcess -}}

Yea, OK, that doesn't work ... well. templates.Defer is replacing resources.PostProcess so having both will give undefined results. It should not crash, so I suspect that's a real issue, but you should remove resources.PostProcess.

I have had some browser live reload issues myself lately (one issue seem to be a newly introduced bug in Chrome). I have pushed a reimplementation (with better info loggin) to Hugo's main branch, but haven't released yet, will soon.

[jloh]

Thanks Bep, I've removed resources.PostProcess and everything is working fine now! I ended up moving it in to my baseof.html like your example then copying the rest of that. Final code looked like this:

{{ with (templates.Defer (dict "key" "global")) -}}
	{{- $options := (dict "inlineImports" true ) -}}
	{{- $tailwind := resources.Get "css/main.css" | resources.PostCSS $options -}}
	{{- if hugo.IsDevelopment -}}
		<link rel="stylesheet" href="{{ $tailwind.RelPermalink }}" />
	{{- else -}}
		{{- $tailwind = $tailwind | resources.Fingerprint "sha512" -}}
		<link
			rel="stylesheet"
			href="{{ $tailwind.RelPermalink }}"
			integrity="{{ $tailwind.Data.Integrity }}"
			crossorigin="anonymous"
		/>
	{{- end -}}
{{- end }}

---

Since moving to the new format I'm now getting a slightly new error:

Change detected, rebuilding site (#1).
2024-07-14 00:06:46.877 +1000
Template changed /_default/_markup/render-link.html
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Total in 37 ms
ERROR Failed to render "/posts/": "/Users/james/code/github/jloh/blog/layouts/_default/baseof.html:1:1": parse failed: html/template: cannot Parse after Execute

Happy to open a new issue if thats easier.

[bep]

Happy to open a new issue if thats easier.

No, it's most likely the same issue, but with a more clear text ...

But I have note been able to reproduce it (I have had a bash script doing some edits in a loop for the last hour ...), but I guess it will eventually happen.

[jloh]

I'll keep an eye out for this but I have a feeling this was fixed in #13155. I haven't experienced it since upgrading to 0.140.x when previously I had it happen quite frequently.

[bep]

I have had the server running with frequent rebuilds with some "defer heavy" projects lately, and I have not seen a single panic, so I'm closing this for now. Someone will certainly re-raise the issue if it happens again.