ASTM NetRID Service Provider notification behavior does not detect notifications

[BenjaminPelletier]

Observed behavior
This scenario claims a notification was not received when the interactions from mock_uss appear to show it was received.

sequence.zip

See s27e14; the notification from uss1 can be found in item_13 of response.json.interactions as ISA 1ee94447-d6be-4fbc-a3f5-f55c1180fc38 is the one uss1 created per s27e7 response.json.log_messages. Likewise for uss2 in item_14 with ISA f60fed9c-0713-483d-8a6e-49262c9ea2d6.

Test check
Service Provider notification was received

Difference from expected behavior
uss_qualifier should have found the notification and therefore passed the check.

I suspect this may not be failing in CI because we reuse the same mock_uss for multiple roles; we may want to consider adjusting that.

As a side note, I would expect the relevant queries to be included in the failed check information (via query_timestamps) to allow optimal debugging.

[the-glu]

The test use the id defined in the services provider configuration, here uss1_core. However, the recorded notifications are with uss1.

I don't see another obvious way to map the SP with the notification (e.g. with uss_base_url).

Is this dues to a misconfiguration and participant_id must be set to the expected id in the notification? Or the notification is wrongly recorded?

(Edit: It seems to use the token subject, so I would assume they need to match and that indeed a configuration error?)

This can be reproduced with standards tests by changing SP configuration, eg.:

netrid_service_providers_v22a:
  $content_schema: monitoring/uss_qualifier/resources/definitions/ResourceDeclaration.json
  resource_type: resources.netrid.NetRIDServiceProviders
  dependencies:
    auth_adapter: utm_auth
  specification:
    service_providers:
      - participant_id: uss1_core
        injection_base_url: http://v22a.ridsp.uss1.localutm/ridsp/injection

[BenjaminPelletier]

It seems to use the token subject, so I would assume they need to match and that indeed a configuration error?)

Ah, that seems like the problem -- there is no reason to think the token subject will match the participant ID in the test (and it usually doesn't). The normal means to determine a participant responsible for a resource/interaction/etc is with a USSIdentificationResource.