-
Notifications
You must be signed in to change notification settings - Fork 243
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
Correcting the responder requests to actually match the API #251
Conversation
Message string `json:"message"` | ||
RequesterID string `json:"requester_id"` | ||
Targets []ResponderRequestTarget `json:"-"` | ||
NestedTargets []ResponderRequestTargets `json:"responder_request_targets"` |
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.
Thanks for trying to keep this backwards compatible! However, if it's never worked (and that's on me because I reviewed the original PR) would it make sense to simply fix the Targets
field to be []ResponderRequestTargets
, similar to how you did in ResponderRequests
?
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.
To be honest, the DX of doing the construction with []ResponderRequestTarget
does feel more intuitive and I can easily see people getting confused in the future to be honest if having to build []ResponderRequestTargets
themselves. I postulate that's probably why the mistake was made to implement it like that originally.
On the other hand, what you get back is different enough you're not expecting consistency and as the developer isn't the one building it, it doesn't matter so much.
@michael-bud there are a few cases in this library where things were introduced that seem to have never worked, and so I'm proposing a My justification for v1.5.0 over v2.0.0 is...
Would you be willing to resolve the merge conflict and update this PR to be a breaking change that we target for |
Since we've not heard from you we'll close this in favor of #328. |
It looks like this never actually worked and it doesn't match the API.
A correct request:
What it was generating as a request (which would result [unhelpfully] in just an undescriptive 404 error back from pagerduty):
Also the response would generate this error as the response has an array of targets:
Unfortunately, there didn't seem like a nice way to keep BC for this - that said, this never worked before anyway so I guess nobody is using it?
It appears the docs used to be wrong on this which is probably where it came from:
https://community.pagerduty.com/forum/t/create-responder-api-call-failing/226
It's worth noting the pagerduty API docs are also still wrong. The example is correct, but the schema is wrong: https://developer.pagerduty.com/api-reference/reference/REST/openapiv3.json/paths/~1incidents~1%7Bid%7D~1responder_requests/post
I have tested this fix locally with this code in a mock command and it works. I've tried to maintain BC also:
I'd appreciate it if a tag could be done after merging this PR so I can pull the change down. Thanks!