failed to cache strings

[nexovec]

Discussed in #869

^{Originally posted by nexovec August 2, 2024}

I'm getting this weird message rendered instead of my templates.

templ: failed to cache strings: templ: failed to stat /app/internal/templates/v1/common_templ.txt: stat /app/internal/templates/v1/common_templ.txt: no such file or directory

I don't really know how to reproduce this or what it even means, but seems that this sometimes happens when I use templ generate and templ generate --watch interchangeably. I don't use any .txt file anywhere and it's been working just fine until you added some sort of caching for watchmode. What is this?

There are other people that had this issue in the discussion.

[MilkeeyCat]

Hey! Seems like templ creates _templ.txt file for caching string literals. So when you run templ generate command with -watch flag it uses this file but when you stop the process it replaces the calls to the function which fetches data from that file to regular string literals.

The only reason of the problem I can think of is that maybe you were running templ generate -watch command and you commited generated _templ.go and you have Dockerfile which just copies go files. Or maybe you removed .txt yourself.

[a-h]

That's right. We need to fix it so that the code is identical between dev and prod mode, with a runtime switch to change behaviour.

I think I got it sorted in a branch last month: main...watch_mode_prod_mode_generate_same

But I went on holiday, then got caught up in work projects, so I need to dust it off and check how far along I got.

[MilkeeyCat]

@a-h Do you want to have the same code in dev & prod modes to not have such problems or production generated code would also somehow benefit by using cached string literals?

[a-h]

It would be to avoid problems caused by deploying watch mode code. There's no benefit in a production scenario that I can think of.

[nexovec]

Sometimes I'm still getting the error message, but now restarting the app and templ seems to be enough to fix the thing(now templ v0.2.778). I will double check the error contents when I get it again just to not cause false alarms here.