You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you run npm test -- test/flows/book-only/ against the reference implementation on master now you'll see the issues for C1 validation - it's still not running. Very strange!
Perhaps there's some kind of race condition or similar happening here?
I think I've also might have identified the cause of one of the "race conditions". It looks like the flows are lacking some defensive programming for cases where a prerequisite call fails - specifically those calls that hit the microservice and wait for the feed - getMatch and getOrder. I've made a quick fix for getMatch, but we need something similar for getOrder.
It's also probably worth stopping all the main calls C1, C2, B etc executing if the opportunity couldn't be retrieved from the feed for some reason, as it'll just hit the booking system with loads of broken requests otherwise after the timeout (which may cause more race conditions?). I've tried to do this here but haven't quite managed it: ec96f67#diff-7ec38b867eb5885e1977c92e06a66053
When this issue is closed the tests should be robust regardless of the response times of the endpoints.
The text was updated successfully, but these errors were encountered:
"I think I've also might have identified the cause of one of the "race conditions". It looks like the flows are lacking some defensive programming for cases where a prerequisite call fails - specifically those calls that hit the microservice and wait for the feed "
Yeah, looks like the case. Usually exceptions would be relied on for this, but chakram itself doesn't raise exceptions for non-200's.
If you run
npm test -- test/flows/book-only/
against the reference implementation on master now you'll see the issues for C1 validation - it's still not running. Very strange!And if you try pointing it at https://everyoneactivebookingfacade-test.azurewebsites.net/, then many of the endpoints don't validate
Perhaps there's some kind of race condition or similar happening here?
I think I've also might have identified the cause of one of the "race conditions". It looks like the flows are lacking some defensive programming for cases where a prerequisite call fails - specifically those calls that hit the microservice and wait for the feed - getMatch and getOrder. I've made a quick fix for
getMatch
, but we need something similar forgetOrder
.It's also probably worth stopping all the main calls C1, C2, B etc executing if the opportunity couldn't be retrieved from the feed for some reason, as it'll just hit the booking system with loads of broken requests otherwise after the timeout (which may cause more race conditions?). I've tried to do this here but haven't quite managed it: ec96f67#diff-7ec38b867eb5885e1977c92e06a66053
When this issue is closed the tests should be robust regardless of the response times of the endpoints.
The text was updated successfully, but these errors were encountered: