Panic: invalid taxonomy state [0.55]

#1

My site rendered fine with 0.54. On 0.55, I get the error:

panic: invalid taxonomy state for /path/to/content/categories/the-work/_index.en.md with sections [categories the-work

goroutine 197 [running]:
github.com/gohugoio/hugo/hugolib.(*pageState).getTaxonomyNodeInfo(0xc0556535f0, 0xc0556cae40)
/root/project/hugo/hugolib/page.go:744 +0x1e7
github.com/gohugoio/hugo/hugolib.(*HugoSites).createMissingPages(0xc000466fc0, 0x0, 0x0)
/root/project/hugo/hugolib/hugo_sites.go:653 +0x339
github.com/gohugoio/hugo/hugolib.(*HugoSites).assemble(0xc000466fc0, 0xc055417540, 0xc0005f5c70, 0x20)
/root/project/hugo/hugolib/hugo_sites_build.go:245 +0x13a
github.com/gohugoio/hugo/hugolib.(*HugoSites).Build.func2.2()
/root/project/hugo/hugolib/hugo_sites_build.go:98 +0x3c
runtime/trace.WithRegion(0x1239dc0, 0xc05541d5f0, 0xfe2c7a, 0x8, 0xc0005f5d20)
/usr/local/go/src/runtime/trace/annotation.go:137 +0xe9
github.com/gohugoio/hugo/hugolib.(*HugoSites).Build.func2(0xc0007e05c0, 0x20)
/root/project/hugo/hugolib/hugo_sites_build.go:100 +0x23d
github.com/gohugoio/hugo/hugolib.(*HugoSites).Build.func3()
/root/project/hugo/hugolib/hugo_sites_build.go:109 +0x2f
runtime/trace.WithRegion(0x1239dc0, 0xc05541d5f0, 0xfdfc99, 0x7, 0xc0007e06c8)
/usr/local/go/src/runtime/trace/annotation.go:137 +0xe9
github.com/gohugoio/hugo/hugolib.(*HugoSites).Build(0xc000466fc0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, …)
/root/project/hugo/hugolib/hugo_sites_build.go:111 +0x7bd
github.com/gohugoio/hugo/commands.(*commandeer).buildSites(…)
/root/project/hugo/commands/hugo.go:763
github.com/gohugoio/hugo/commands.(*commandeer).fullBuild.func3(0x8, 0x108fdd0)
/root/project/hugo/commands/hugo.go:313 +0x79
golang.org/x/sync/errgroup.(*Group).Go.func1(0xc05541d5c0, 0xc055441a40)
/go/pkg/mod/golang.org/x/sync@v0.0.0-20180314180146-1d60e4601c6f/errgroup/errgroup.go:58 +0x57
created by golang.org/x/sync/errgroup.(*Group).Go
/go/pkg/mod/golang.org/x/sync@v0.0.0-20180314180146-1d60e4601c6f/errgroup/errgroup.go:55 +0x66

(There should be a closing bracket ] after “the-work”, but if I include that here, then the summary/details format breaks.)

My file /path/to/categories/the-work/_index.en.md has the contents:

---
title: "The Work" # this is set automatically based on config.LANGUAGE.toml. Do not change it here.
url: the-work/ # this is set automatically based on config.LANGUAGE.toml. Do not change it here.
translationKey: the-work  # this is set automatically. Do not change.
---

I haven’t investigated very much, because I don’t know where to start. I do know that “the-work” in “[categories the-work]” in the error message comes from the path, not from the contents of the file. If I rename the path to content/categories/the-work2, then the panic error message also uses the-work2. If I edit “the-work” within _index.en.md it doesn’t change the error message.

I appreciate any suggestions for how to troubleshoot this!

1 Like

#3

I have the same Issue. My GitLab pipeline stopped working after I made some changes in forestry. I downgraded to 0.54.0 and everything was working again as expected.

On a blog I created, I implemented the authors as taxonomies as it’s done in this tutorial: https://www.netlify.com/blog/2018/07/24/hugo-tips-how-to-create-author-pages/

In summary:

  • Authors are declared as taxonomy in config.toml
  • Author’s ‘data’ resides inside 'content/authors//_index.md
  • List of authors is layouted by ‘layouts/authors/terms.html’
  • Author’s page is layouted by 'layouts/authors/list.html"

This worked fine in Hugo 0.54.0, but fails with the following error in Hugo 0.55.0:

Building sites … panic: invalid taxonomy state for 
"D:\\...\\content\\authors\\test-author\\_index.md" with sections [authors test-author]

goroutine 76 [running]:
github.com/gohugoio/hugo/hugolib. 
(*pageState).getTaxonomyNodeInfo(0xc00082e150, 0x1011e7a)
    /root/project/hugo/hugolib/page.go:744 +0x1ee
github.com/gohugoio/hugo/hugolib. 
(*HugoSites).createMissingPages(0xc000388000, 0x0, 0x0)
    /root/project/hugo/hugolib/hugo_sites.go:653 +0x340
github.com/gohugoio/hugo/hugolib. 
(*HugoSites).assemble(0xc000388000, 0xc00046b480, 0xc0007b9c70, 0x20)
    /root/project/hugo/hugolib/hugo_sites_build.go:245 +0x141
github.com/gohugoio/hugo/hugolib.(*HugoSites).Build.func2.2()
    /root/project/hugo/hugolib/hugo_sites_build.go:98 +0x43
runtime/trace.WithRegion(0x124a340, 0xc00074cf90, 0xff51a6, 0x8, 0xc0007b9d20)
    /usr/local/go/src/runtime/trace/annotation.go:137 +0xf0
github.com/gohugoio/hugo/hugolib. (*HugoSites).Build.func2(0xc000579dc0, 0x20)
    /root/project/hugo/hugolib/hugo_sites_build.go:100 +0x244
github.com/gohugoio/hugo/hugolib.(*HugoSites).Build.func3()
    /root/project/hugo/hugolib/hugo_sites_build.go:109 +0x36
runtime/trace.WithRegion(0x124a340, 0xc00074cf90, 0xff223b, 0x7, 0xc000579ec8)
    /usr/local/go/src/runtime/trace/annotation.go:137 +0xf0
github.com/gohugoio/hugo/hugolib.(*HugoSites).Build(0xc000388000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
    /root/project/hugo/hugolib/hugo_sites_build.go:111 +0x7c4
github.com/gohugoio/hugo/commands.(*commandeer).buildSites(...)
    /root/project/hugo/commands/hugo.go:763
github.com/gohugoio/hugo/commands.(*commandeer).fullBuild.func3(0x8, 0x10a34b0)
    /root/project/hugo/commands/hugo.go:313 +0x80
golang.org/x/sync/errgroup.(*Group).Go.func1(0xc00074cf60, 0xc000531dd0)
    /go/pkg/mod/golang.org/x/sync@v0.0.0-20180314180146-1d60e4601c6f/errgroup/errgroup.go:58 +0x5e
created by golang.org/x/sync/errgroup.(*Group).Go
    /go/pkg/mod/golang.org/x/sync@v0.0.0-20180314180146-1d60e4601c6f/errgroup/errgroup.go:55 +0x6d

Scanning over the changes in 0.55.0 I id not find any major change that would account for this.

I created a basic git example to test this behaviour: https://gitlab.com/Ukmasmu/hugo-0.55.0-taxonomy-change

It should work fine with Hugo 0.54.0, but the build error should appear in Hugo 0.55.0.

Thank you in advance.

0 Likes

#4

This is obviously a bug and if would be great if you could create an issue here:

0 Likes

#5

Okay, thanks!

I opened the issue #5847.

0 Likes

#6

This problem was fixed in 0.55.2. Thanks!

1 Like