Checks using asset not assigned, but named similarly

Hello, I could use some help, explanation on something i am having a really hard time understanding regarding assets. We have our assets defined in yaml files. we have seen, when similarly named assets are added (will post examples in thread), they are sometimes picked up by checks that are defining one of the other similarly named assets, or all of them. For information, i am using sensugo 5.21.

so for example, i have a check, in the yaml, i am referencing

    "runtime_assets": ["sensu-plugins-kubernetes","sensu-ruby-runtime-2.4.4"],

this same check, if i look at the sensuctl info, shows as expected:
Runtime Assets: sensu-plugins-kubernetes, sensu-ruby-runtime-2.4.4
but in the webUI i see:

Why is this showing like that, and how can i be sure what asset is actually running? First i thought the webUI was just reporting incorrectly, but then:

we have a in-house written asset, lets call it asset-name we recently made a fairly large update to it, so created asset-name-test and changed a single check to use it, for testing and verification. well, in the asset definition yaml, we had a typo in the URL, so we got a failed check with a message that the asset couldnt be grabbed, and a 404 status code, makes sense, right.

but then every check that uses asset-name also started failing with the same error, even though those check configs are not configured to use asset-name-test. I cant find anything in the docs to explain this, and would love some help.

:thinking: I’ve read over this a couple of times now and still am not making sense of the behavior. The only thing that comes to mind is that you’re on 5.21. That’s coming up on 2 years old and there have been quite a number of fixes since then. My suggestion would be to update to a supported release (see Supported versions - Sensu Docs).

How can i be more clear in explaining the behavior if that is the issue, i would really like to be able to communicate it best so that it could be potentially resolved, or at least understood. I am also having a hard time making sense of the behavior as you can see… We cannot upgrade to a newer version at this time, as we are strapped for man hours, and need to test the upgrade to 6.X before we go prod, etc…