[uss_qualifier] check that implicit SCD subscriptions are properly managed #720
Conversation
Shastick
force-pushed
the
415-implicit-sub-handling-scenario
branch
4 times, most recently
from
7f398f0
to
320a048
Compare
Shastick
force-pushed
the
415-implicit-sub-handling-scenario
branch
from
320a048
to
bcc58d4
Compare
Shastick
force-pushed
the
415-implicit-sub-handling-scenario
branch
2 times, most recently
from
894d49a
to
5049594
Compare
Shastick
force-pushed
the
415-implicit-sub-handling-scenario
branch
3 times, most recently
from
6cd5357
to
5b95b39
Compare
Shastick
force-pushed
the
415-implicit-sub-handling-scenario
branch
from
5b95b39
to
4bb3b4d
Compare
monitoring/monitorlib/fetch/scd.py
Outdated
| @@ -375,10 +375,17 @@ def constraints( | |||
| class FetchedSubscription(fetch.Query): | |||
| @property | |||
| def success(self) -> bool: | |||
| """ | |||
| Returns: True if the query was successful OR if it returned a 404. | |||
There was a problem hiding this comment.
I don't think a FetchedSubscription should be considered successful if it returned a 404 (in that case, the subscription was not fetched successfully). I think we can make a was_not_found property (or similar) that we can check in conjunction with success to determine the full state.
There was a problem hiding this comment.
That sounds like a good idea. I'll split this out to another PR, as I believe that not considering 404 a success will require some adaptations in other scenarios
There was a problem hiding this comment.
This change has been split out to #785
|
|
||
| ## 🛑 Implicit subscription has correct temporal parameters check | ||
|
|
||
| If the implicit subscription time boundaries do not match the OIR's, either one, or both, of the following are possible: |
There was a problem hiding this comment.
| If the implicit subscription time boundaries do not match the OIR's, either one, or both, of the following are possible: | |
| If the implicit subscription time boundaries do not cover the OIR's, either one, or both, of the following are possible: |
| If the implicit subscription time boundaries do not match the OIR's, either one, or both, of the following are possible: | ||
|
|
||
| The DSS is in violation of **[astm.f3548.v21.DSS0005,1](../../../../../../requirements/astm/f3548/v21.md)**, as the implicit subscription does not cover the OIR's time boundaries; | ||
| Entities that should have been cleaned up earlier are still present in the DSS, and this scenario cannot proceed. |
There was a problem hiding this comment.
We should be able to differentiate between these two causes, and the requirement not to have cleaned-up entities in the DSS should be identified. Presumably, this is the ClearArea requirement, and presumably that check was already performed when clearing the area (so we don't need to refer to it again here since we know it's not the cause since the earlier clearing succeeded).
Shastick
force-pushed
the
415-implicit-sub-handling-scenario
branch
from
4bb3b4d
to
4384d44
Compare
Shastick
force-pushed
the
415-implicit-sub-handling-scenario
branch
from
4384d44
to
c847d78
Compare
Shastick
force-pushed
the
415-implicit-sub-handling-scenario
branch
from
c847d78
to
f09bb70
Compare
PR for a scenario addressing implicit subscription handling, based on checks proposed in #415.
This depends on this DSS fix to be merged and released. The PR was tested locally against a fixed DSS and the scenario passes.
Some improvements that we could add in later PRs
Misc
force_no_implicit_subscriptionto theput_op_intentfunction in F3548'sdss.pyto allow callers to create an OIR without any implicit subscription (which is allowed for OIRs in the ACCEPTED state)This scenario covers the implicit cleanup fix on the DSS repo and covers some of the corner cases mentioned in interuss/dss#1088