The simplest reproducer is:
```json
{{< sc >}}
```
Error: error building site: render: failed to render pages: render of “home” failed: “/home/jmooring/code/hugo-testing/layouts/_default/home.html:11:5”: execute of template failed: template: _default/home.html:11:5: executing “main” at <.Content>: error calling Content: unknown shortcode token “HAHAHUGOSHORTCODE<span style="color:#ae81ff">1<span style="color:#960050;background-color:#1e0010">s<span style="color:#ae81ff">0<span style="color:#960050;background-color:#1e0010">HBHB” (number of tokens: 1)
Your example, with an un-closed fenced code block, is equivalent to the above. The parser doesn’t read ahead to look for a matching closer (see this thread for details), and your markdown is valid despite the lack of a matching closer.
There may be other highlighting languages that trigger the same problem. I tested about 20 other languages, including some likely suspects, but was unable to reproduce the problem.
This isn’t a problem if you call the shortcode using the {{% %}} notation.
Since your markdown is valid, you can’t use a markdown linter to find un-closed fenced code blocks. So, as you have found, your best option is a regex search (e.g., ^``$).
I’ll log a bug for this, but it is so edge-casey I wouldn’t be surprised if it lingers in the issue queue until it dies of neglect.