-
Notifications
You must be signed in to change notification settings - Fork 44
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
Resolve meraki webhook fail when none defined #436
Merged
kbreit
merged 5 commits into
CiscoDevNet:master
from
mystery-rabbit:Resolve_meraki_webhook_fail_when_none_defined
Feb 1, 2023
Merged
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
e3dc5d7
Added test coverage to check behaviour when there are no webhooks def…
mystery-rabbit af21031
removed hard coded list subscript to make sanitize_no_log_values cope…
mystery-rabbit 92a2efc
resolved linting and sanity errors
mystery-rabbit 12fa186
Added changelog fragment
mystery-rabbit 16c45a7
refactored patch to correctly deal with the variety of types
mystery-rabbit File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
2 changes: 2 additions & 0 deletions
2
changelogs/fragments/433_Resolve_meraki_webhook_fail_when_none_defined.yml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
bugfixes: | ||
- Resolved an issue where an empty response from the API triggered an exception in module meraki_webhook (https://github.com/CiscoDevNet/ansible-meraki/issues/433) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Overall this looks good but should there be a new test looking for the
shared_secret
value?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.
We can certainly use the opportunity to call out the expected behaviour via the test cases yes. that's probably just the de-commenting of the idempotency tests and tightening the assert statements.
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.
@kbreit
I added a test to my local branch testing that a seemingly idempotent change is always going to return "changed" and no shared_secret. passed.
I then added a test that did a change without shared_secret set - expecting changed='false' - and that's picked up another issue.
API behaviour - if the shared secret is not set in the request, then the API will still return 200 OK - it does not touch the secret - only updating any changed params. (verified through GUI/Postman)
module behaviour - if the shared secret param is not set, the module will set shared secret to null, and send that - API will return 400 Error. To my mind, it should not be setting the param at all.
I can see how to resolve that - any issues with me adding that to the PR?