[uss_qualifier] rid: dss0130 - check information relative to intersecting entities is properly sync'd #839
Conversation
Shastick
force-pushed
the
dss-0130-sub-interaction-across-dss
branch
3 times, most recently
from
5f77be2 to
4fa7a58
Compare
Shastick
force-pushed
the
dss-0130-sub-interaction-across-dss
branch
from
4fa7a58 to
7801228
Compare
|
Reverted the open TODO |
Shastick
force-pushed
the
dss-0130-sub-interaction-across-dss
branch
from
7801228 to
7e93100
Compare
|
|
||
| #### ⚠️ ISA modification on secondary DSS triggers subscription notification requests check | ||
|
|
||
| **[astm.f3411.v19.DSS0130,A2-6-1,3c](../../../../requirements/astm/f3411/v19.md)** and **[astm.f3411.v19.DSS0130,2,e](../../../../requirements/astm/f3411/v19.md)** |
There was a problem hiding this comment.
I'm not sure it is fair to fail DSS0130,2,e here, there could a number of other reasons than the area not being synchronized.
Why not validating that simply by querying secondary DSSs in a different place?
There was a problem hiding this comment.
If this check fails, we may not be able to tell exactly why. We've had checks fail multiple requirements that are pretty different (some related to API while others are related to synchronization) for SCD (see eg here).
The wording could be improved here, though I'd be happy to do that in a separate PR and make this whole page more verbose.
Why not validating that simply by querying secondary DSSs in a different place?
That might be a valid additional check that might partially cover the requirement: if we create an ISA in another area we would expect to not find the subscriptions not covering it, but that would still not allows us to conclude that the subscription's area has been properly synced?
Possibly the check needs rephrasing and we should use or instead of and, but creating a subscription on DSS A then doing something on DSS B in a similar area and expect to run into the subscription is pretty much how we said we would test this requirement at the community meeting ~10 days ago.
| subs_to_notify_sec = [] | ||
| for subscriber in mutated_isa_sec.subscribers: | ||
| for s in subscriber.raw.subscriptions: | ||
| subs_to_notify_sec.append(s.subscription_id) | ||
|
|
||
| with self.check( | ||
| "ISA modification on secondary DSS triggers subscription notification requests", | ||
| [self._dss_primary.participant_id], | ||
| ) as check: | ||
| if sub_1_0.uuid not in subs_to_notify_sec: | ||
| check.record_failed( | ||
| summary=f"Subscription {sub_1_0.uuid} was not notified of ISA modification", | ||
| details=f"Subscription {sub_1_0.uuid} was created on the primary DSS and should have been notified of the ISA modification that happened on the primary DSS, but was not.", | ||
| ) |
There was a problem hiding this comment.
This here will take into account only the last secondary DSS. Why not:
- put that inside the for loop
- add the secondary DSS as participant in the check
- add in check details both primary and secondary DSSs participant IDs
There was a problem hiding this comment.
Good catch, I think that this was the original intention, will fix.
Shastick
force-pushed
the
dss-0130-sub-interaction-across-dss
branch
4 times, most recently
from
378724d to
3320566
Compare
monitoring/uss_qualifier/scenarios/astm/netrid/common/dss_interoperability.py
Outdated
Show resolved
Hide resolved
monitoring/uss_qualifier/scenarios/astm/netrid/common/dss_interoperability.py
Outdated
Show resolved
Hide resolved
Shastick
force-pushed
the
dss-0130-sub-interaction-across-dss
branch
3 times, most recently
from
41331d2 to
02f094d
Compare
…ting entities is properly synchronized
mickmis
force-pushed
the
dss-0130-sub-interaction-across-dss
branch
from
02f094d to
cb41723
Compare
…ting entities is properly sync'd (#839) Co-authored-by: Mickaël Misbach <[email protected]> 346b780
Probe the secondary DSS's to check that they have all required information to return the proper subscriptions relevant to an ISA.
Builds on top of #838, please only review the last commit.
Part of the effort on #754