Developers: What do you do to make your layout files "debuggable"

dev
1

Hi all (developers). I ran into some hassles with the new release: It doesn’t like my setup anymore…

Error: Error building site: "/home/patrick/github.com/dnb-org/dnb-hugo-auditor/content/index/by/last-changed.md:1:1": timed out initializing value. You may have a circular loop in a shortcode, or your site may have resources that take longer to build than the `timeout` limit in your Hugo config file.

My setup is too big, I know. I have plenty of modules with local replacement rules (the repo in the link is using the published tags). Then I do all the CLI parameters to show template metrics and move the localhost to an IP/Port setup so I can test on other devices on my network.

Updating from 0.92.2 to 0.93.0 leads to 100% of these errors above. Before that error came up maybe once in a while (as in once a week or less). It also does not come up at the same file, line, character location and also not from the same module. Just like you would expect in a timeout. I have no timeout though in my config.

Running just hugo server without any module replacement leads to site execution in max 30 seconds. Removing all local module replacements is helping. The site is running. Now enabling each module replacement one by one will lead to the culprit(s).

From a developer’s point of view (coming from PHP, sorry) though this is not really what I would expect. Is there any way to debug in a more automatic verbose way what Hugo exactly was doing when it failed? I have no problem digging through the dirt to end up at SOMETHING usable. The way Hugo works now (and I know I complained about this about every 6 months now) is not really helpful and I am pretty sure that is because of how Golang and the parallel execution thingy works.

I know the whole “one feature per module” approach I have might be what’s killing me here, but I am a believer in easily reproducible features. Like a menu at a restaurant :wink: Let’s add some header tags, some sitemaps and deploy at netlify (= 3 modules).

So basically, what I am trying to find out is what others (you) do to make their modules or even “just” themes easily “debuggable”.

My approach, should nothing better turn up, will be to implement a paranoic debugging feature that uses error reporting levels where the most verbose is “going into this file, doing that range, done with that range, doing this if-else statement”. But honestly… that will feel very very weird and will clutter up the templates.

In a perfect world hugo server --debug would suddenly start putting a lot of traceroutes for all the template tags it’s encounters into the logfile.

How do you do it? (No answer is wrong if it helps, hehe)

PS: Extra points if you can somehow find a better explanation on why Hugo would throw an “ehm, it’s maybe probably a timeout” error and what would be the errors that might not be timeout related at this point.

PPS: I seriously started to watch a Go Beginners course and Go for Programmers course I got myself a while back at stackskills.com, but I guess it will take a while until I have some level of useful understanding of the intestines of Hugo. And graphs via markdown are just to enticing…

1 Like
2

By the way, shameless self-marketing here, I added a while back a partial to dnb-hugo-debug that does debug into the log which is what I am using to debug from within my partials/layouts. The module is based on kaushalmodi/hugo-debugprint.

The problem with this approach is a certain level of “pollution”. Without too much extra code it’s impossible to make Hugo NOT go through that partial anytime it’s called. The partial itself is the one deciding if the “log level” is high enough to cry into the log.

3

I have no clue as to why these errors come up in these release. They are timeouts and as such I think they are real …

That said, the work I started here may be of (future) help to you: work in progress: Add page template func / context all the way down by bep · Pull Request #9570 · gohugoio/hugo · GitHub

I started on a “what is this” in that issue, but I can add here:

  • That it should enable us to do timeouts/cancellation on a higher level
  • It should enable us to (with some effort) to create a stack trace (showing the template execution down through the layers).
3 Likes
4

OK, I do have a clue as to why these may be more frequent, (because of the code block render hook thing, more of the content gets rendered with a timeout set), but I have tested this pretty good and have not noticed any noticeable negative side effect from it. But I’m happy to help investigate if you could share your source.

5

It’s in my repo, but it only occurs when I have the local replacements going on.

So I think it might be a slowing down due to hardware (slow harddrive? if many processes touch files at the same time my media player is stuttering ;)) or something with local replacements for Hugo Modules… But I really don’t want you to waste your time with checking out and testing my 20-30 modules. I am going through them slowly and will try to find out if one of them is doing something weird.

As long as you are saying it’s connected to timeouts I am going to try to find what is slowing it down and eliminate those.

edit: The whole local replace command thingy is here:

6

But given that, setting the timout to something very high should be a good medicine.

1 Like