sp_HumanEventsBlockViewer always reads the system_health event file, even when asked for its ring buffer

[ReeceGoding]

Version of the script
Current dev branch.

What is the current behavior?
As discussed here, I cannot see any evidence to suggest that sp_HumanEventsBlockViewer is capable of reading the ring buffer version of the system_health Extended Event. As best as I can tell, it reads the event file even if you tell it not to. Moreover, I think that passing in @target_type as anything but NULL results in the event file being read.

If the current behavior is a bug, please provide the steps to reproduce.
On a system with some recent blocking, compare these:

EXEC sp_HumanEventsBlockViewer @target_type = 'ring_buffer', @session_name = 'system_health'
EXEC sp_HumanEventsBlockViewer @target_type = 'event_file', @session_name = 'system_health'
EXEC sp_HumanEventsBlockViewer @target_type = 'foobar', @session_name = 'system_health'

In my experience, they are always the same.

What is the expected behavior?
When asked to read the ring buffer version of the System_Health Extended Event, either error out or actually do it. When I request total nonsense, inform me that I've been silly.

Which versions of SQL Server and which OS are affected by this issue? Did this work in previous versions of our procedures?
I think that sp_HumanEventsBlockViewer has always been like this.

IMPORTANT: If you're going to contribute code, please read the contributing guide first.
https://github.com/erikdarlingdata/DarlingData/blob/main/CONTRIBUTING.md
I can't help with this one. I don't know the internals of sp_HumanEventsBlockViewer well enough.

[erikdarlingdata]

@ReeceGoding if you really feel like working this, it's fine. There's not a ton of utility in the ring buffer, and it's only in there as a last resort for Managed Instance where reading the event file is an absolute nuisance.