After further investigation, I don't see any evidence yet the URL is parsed incorrectly. In prod,
https://en.wikipedia.org/w/index.php?title=Special:GettingStarted/task/copyedit&source=gettingstarted is linked from Special:GettingStarted. The links from the toolbar look like https://en.wikipedia.org/wiki/Special:GettingStarted/task/copyedit?exclude=Tirgan_Festival&source=navbar-next (the exclude varying, of course).

Locally:

http://127.0.0.1:8080/wiki/Special:GettingStarted/task/copyedit?source=gettingstarted (not precisely a URL is generated in prod, but close and a valid URL I expect to be parsed correctly)

http://127.0.0.1:8080/srv/mediawiki/index.php?title=Special:GettingStarted/task/copyedit&source=gettingstarted (local version of one of the prod URLs)

http://127.0.0.1:8080/wiki/Special:GettingStarted/task/copyedit?exclude=Tirgan_Festival&source=navbar-next (local version of the URL shown on the toolbar)

all parse correctly.

There are only a handful of invalid GettingStartedNavbarNoArticle_5483117 events, while there are hundreds of valid ones (including a few from today).

I can reproduce the issue with invalid URLs like:

http://127.0.0.1:8080/srv/mediawiki/index.php?title=Special:GettingStarted/task/copyedit?source=gettingstarted

But I haven't yet seen anywhere the code could generate such a URL. It is possible there's an edge case I missed. However, if the code isn't generating it, it could be an external tool or a URL hacker.

I was not able to find any invalid events (at all, not just for this issue) for GettingStartedNavbar with 5588671 (the current revid) or 5496876 (the prior deployed one).

Hence, bumping priority down for now.

This is low-priority, since the special page will be removed shortly (it now uses an API, and even if there was a bug, it should no longer be present then).