-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[uss_qualifier/scenarios/netrid/dss_interoperability] Avoid timeouts in notifications to dummy subscriptions #518
Conversation
4de8c05
to
613446b
Compare
LONG_WAIT_SEC, | ||
"Subscriptions needs to expire so we can check they don't trigger notifications", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Notes:
- description string updated from my understanding of the code.
- the longer wait time aims at making sure that the subscriptions created at step9 above have expired
@@ -515,7 +518,9 @@ def step9(self): | |||
created_sub = dss.put_sub( | |||
check, | |||
sub_id=sub_2.uuid, | |||
**_default_params(datetime.timedelta(seconds=SHORT_WAIT_SEC)), | |||
**_default_params( | |||
datetime.timedelta(seconds=SHORT_SUBSCRIPTION_DURATION_SEC) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we run into problems again in the future, or if users report that this is brittle when testing real deployments, we could consider:
- making this a configurable part of the scenario, giving users the possibility to trade off execution speed vs delay sensibility
- computing these delays according to the number of DSS's, based on allowed p95 latencies
613446b
to
36306c1
Compare
Will reopen when the root-cause is addressed |
e6e5956
to
55b4925
Compare
55b4925
to
269547c
Compare
This seems to be consistently passing again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
FYI I'm taking the liberty to modify your description so that this PR won't close automatically the related PR.
Don't attempt to notify the short-lived subscriptions that the
dss_interoperability
scenario created, as these result in requests toexample.com
that time out and cause the scenario's assumptions to break.(This uses the recently introduced
do_not_notify
parameter.)This also updates the dummy
uss_base_url
fromexample.com
toexample.interuss.org
to take a step forward regarding #275Evidence this seems to work:
See #517