Fix errors in 9.0 build

[colleenmcginnis]

Fixes the errors I was seeing in the 9.0 build in elastic/docs#3235.

cc @karenzone (I can't request a reviewer in this repo)

[karenzone]

I'm concerned about adding yet another way to handle bad links--we fixed many in logstash-docs-md and we have redirects elsewhere. For example, we fixed lined 64 and 66 in logstash-docs-md.

Is this approach temporary or part of a broader strategy?

[colleenmcginnis]

I don't know. How many PRs would it take to update this link to use {logstash-ref}/dead-letter-queues.html permanently so the change wouldn't be overwritten in future updates? (You've scared me into not wanting to attempt to edit AsciiDoc files at the source. 🙃)

[karenzone]

You've scared me into not wanting to attempt to edit AsciiDoc files at the source.

Any fixes we make in logstash-docs would persist <except for some weird, almost edge case multi-release-during-the-same-stack-version-updates>. Even then, we could see the regression in the diff, and ideally, fix it permanently with your amazing regex skills.

Weird situations like these are one of the reasons that I feel so strongly that our solution should use incremental updates. If we make whatever is in github code persistent unless deliberately overwritten, then we don't have to worry about anything getting stomped ever.

I never meant to scare anybody! :-) There are boundaries, of course, but sometimes fixing in ADOC the best approach. We just need to be sure to fix anything we can in the plugin source.

[bmorelli25]

Weird situations like these are one of the reasons that I feel so strongly that our solution should use incremental updates. If we make whatever is in github code persistent unless deliberately overwritten, then we don't have to worry about anything getting stomped ever.

What's the time commitment required to get to incremental updates? We need to balance effort vs output and I'm hesitant to put a lot of time into building an ideal temporary solution.

[karenzone]

At this point, it's just a wish and a rudimentary idea:
"Generated jobs (VPR and LSR) create new, unique branches for content. When compared against baseline source content, we get a diff. We could take content from the newly created branch, ship it to logstash-docs-md, and run the conversion there (ADOC->MD), touching only changed files. This approach ensures that any manually touched up files persist."

If we think the regenerate-and-overwrite approach is a short-term solution, I'll go along with it. I'd still prefer not to introduce another way to handle redirects, and hard code the link instead.

[colleenmcginnis]

We shouldn't need this with the new approach we're using!