Due to the API sending back a dynamic value based on another attribute setting we're having trouble getting a consistent plan. Behavior appears to be as follows:
waitForNav is needed in the request body
if waitForNavTimeout isn’t provided, the API uses the value from waitForNav to determine the timeout value. so if true, waitForNavTimeout value will be 2000, and if it’s false, then waitForNavTimeout value will be 50
if waitForNavTimeout is provided, it just uses that and the false/true thing from waitForNav doesn’t matter
This can cause us to create a plan that doesn't match either 2000 or 50 correctly due to waitForNavTimeout not being set.
After the change?
Because we can't easily do a check on a different attribute value and make changes to compensate at plan time we are implementing logic to set a static waitForNavTimeout with value of 1000 (this was an arbitrary number) if one isn't set.
We're also adding validation to the input of waitForNavTimeout that it must be an int greater than zero.
Pull request checklist
[ ] Acceptance Tests have been updated, run (make testacc), and pasted in this PR (for bug fixes / features)
[ ] Docs have been reviewed and added / updated if needed (for bug fixes / features)
Resolves #ISSUE_NUMBER
Before the change?
Due to the API sending back a dynamic value based on another attribute setting we're having trouble getting a consistent plan. Behavior appears to be as follows:
waitForNav is needed in the request body if waitForNavTimeout isn’t provided, the API uses the value from waitForNav to determine the timeout value. so if true, waitForNavTimeout value will be 2000, and if it’s false, then waitForNavTimeout value will be 50 if waitForNavTimeout is provided, it just uses that and the false/true thing from waitForNav doesn’t matter This can cause us to create a plan that doesn't match either 2000 or 50 correctly due to waitForNavTimeout not being set.
After the change?
Because we can't easily do a check on a different attribute value and make changes to compensate at plan time we are implementing logic to set a static waitForNavTimeout with value of 1000 (this was an arbitrary number) if one isn't set.
We're also adding validation to the input of waitForNavTimeout that it must be an int greater than zero.
Pull request checklist
make testacc), and pasted in this PR (for bug fixes / features)Acceptance Test Output
Does this introduce a breaking change?