Partial argument dict key mismatch silently masked by incremental rebuild cache

[kobrix]

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

$ Hugo version Hugo v0.161.1

Does this issue reproduce with the latest release?

Yes.

Encountered this yesterday, and it took a while to isolate (I’m a Hugo newbie).

Description

A typo in a partial call’s argument dict (an incorrect key name) produced no error and no visible output change during a live hugo server session, despite the partial depending on that key to render content and no error was reported.

The error only surfaced as a build error after server restart, and only then because an unrelated path change triggered a hunt for why nested partials weren’t being included. Deleting public/ and rebuilding during the session didn’t clear the cached result.

Expected behaviour:

A key name mismatch between the dict passed to a partial and the keys the partial reads should throw a build error or warning of some sort.

Actual behaviour:

Hugo continued serving the previously-cached (correct) output for the partial, entirely masking the error. The session ran across approx 30 commits without any indication that the partial was not being re-evaluated.

Steps to reproduce:

1. Start hugo server with a working partial at layouts/_partials/exhibitions-current.html, called from home.html as partial "exhibitions-current.html"
2. While server running, move partial to layouts/_partials/base/exhibitions-current.html without updating the call in home.html
3. Hugo continues serving the correct output despite the partial now being unreachable at the original path
4. In the same session, introduce a key name mismatch in the dict passed to a nested component partial, e.g. pass "exhibitionss" where the component reads .exhibitions
5. Hugo carries on serving the correct output without giving an error or warning
6. Restart the server. Hugo now errors on the broken path from step 2. Once this is corrected, the key mismatch from step 4 silently produces empty output.

[bep]

Hugo carries on serving the correct output without giving an error or warning

I read your issue twice, and I'm not sure I follow. If the output is correct, why should there be a warning?

I suspect this is about how we do template updates on renames (or deletes) in Hugo. This is from memory, but I think it's correct:

• We do partial rebuild of the template store on changes.
• On renames/deletes we don't remove the old entries, so if you rename partial foo.html to bar.html, both will work.
• This is a known trade-off, assuming that if you rename a template you also need to update the references.

We may make this smarter, but I'm still confused as to what this issue is about.

[kobrix]

Hi bep, I’ll try to clarify:

Tthe output appeared correct before restarting the server, in that fresh and complete data continued to populate the page despite an incorrect path to the partial calling the data. Once the server was restarted this problem surfaced (the incorrect path was flagged, as would be expected).

But this masked the main issue I’m reporting, which is the problem with the mismatched keys. After restarting the server, pages were being generated without reporting an error, but no data was passed through by the specific partial mentioned because of the key mismatch, which wasn’t reported as a build error but just passed over silently.

So there are really two related issues here, firstly being that some sort of caching allowed the rendered draft site to appear as if the partials were properly formed when they weren’t, and secondly (but mainly) that this hid another issue which meant that data wasn’t being found because of a misspelled key. The first was alerted as an error, the second failed silently.

I hope this makes sense!

[bep]

Let's ask a different question, if you

1. Start hugo server with a working partial at layouts/_partials/exhibitions-current.html, called from home.html as partial "exhibitions-current.html"
2. While server running, move partial to layouts/_partials/base/exhibitions-current.html AND updating the call in home.html

Does it then work correctly?

[kobrix]

I’ve obviously confused matters!

I’m not concerned about the business with the partials beyond that Hugo’s caching hid the main problem I hit, which is the mismatched keys issue and that fact that Hugo doesn’t report this as an error.

It took me a while to work out that the reason I wasn’t getting any data through after the restart was because I had misspelled the key (as in step 4 of my original post). This spelling error was introduced many edits prior to restarting the server, and the fact that data had continued to appear as expected in the draft site meant that I was looking at more recent edits for the culprit.

Now I have learned that Hugo doesn’t do a clean rebuild unless via a server restart I’ll be aware of that in future. But like I said, that isn’t the main issue.

[kobrix]

How the saga unfolded:

1. I was working happily updating data, with server running
2. I decided to split my partials into a base/ folder and nested partial in components/
3. I neglected to update paths in home.html with new base/ element
4. I carried on working, adding data to yml, which appeared in pages as expected
5. for unrelated reasons, I restarted the server
6. Hugo reported that it couldn’t find layouts/_partials/exhibitions-current.html
7. I realised that I had neglected to add base/ to the path, which I corrected
8. Hugo rebuilt the draft site without reporting any error, but this time some data was missing
9. I shut down the server, removed public/ and restarted server. No joy.
10. I eventually found that a dict key mismatch (an extra s) had been introduced at point 2 (above) but this was not caught as an error at the time by Hugo, nor was it apparent to this newbie until much later because of ignorance of Hugo’s caching behaviour.
11. I consumed much of my own time finding root of the error, and then consumed @bep’s time by not being clear enough in my original report. For which, profound apologies.