-
Notifications
You must be signed in to change notification settings - Fork 349
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
Callbacks #716
Callbacks #716
Conversation
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.
Had a quick look into. Good start :)
I've explored a little bit the possibility of using an ABNF interpreter but effectively it's not worth the hassle. We'll keep the source code specific.
…hooks # Conflicts: # packages/cli/src/commands/mock.ts # packages/http/package.json # packages/http/src/mocker/index.ts
Yep, I've been also looking into some more automatic way of interpreting the syntax. Especially that the ABNF syntax was given. However, I ended feeling that it is too much to carry the whole engine just for resolving such simple syntax. |
Yeah that's totally legit. I'm jumping on this right now! |
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.
Very good stuff. The general direction is great and the implementation is basically almost the same I'd have written by myself.
I've dropped a first pass of comments but I had to stop because of TypeScript complaining about the missing updated packages that we need to sort out.
Very good stuff @StefanDywersant.
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.
Dropped another bunch of comments!
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.
There are other changes to do but it's mostly about code organisation and stuff — the feature looks good to me. I'm now going to pull the branch down and test the hooks in general.
@philsturgeon I think it's time for you as well to test down this and see if this is working in the way you want.
Very good job @StefanDywersant — we're about to ship a very good and unique feature in the mock servers space.
I've also marked this as ready to review since I've reviewed it at least 3 times
* refactor: unknown error * format: mardkwon file * refactor: improve chain call
This is so cool, amazing work @StefanDywersant. One thing could do with a bit of polish: I was using https://webhook.site/ which is a cool request bin type thing which captures webhooks for testing. Apparently their API is not responding quite how Prism would like: I guess it's because the callback has rather specific requirements for the callback: callbacks:
actions:
'{$request.body#/url}?token={$request.body#/token}':
post:
summary: 'Receive notification about certain invoice'
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/notification'
responses:
200:
description: 'Notification successfully processed'
content:
text/plain:
examples:
ok:
value: 'ok' Here is what it responded with:
Anyhow, the error message it gives is not as descriptive as it could be.
Maaaybe that should actually be displayed as [CALLBACK]? Or if not, a super clear message:
Beyond the error message, I suppose if somebody wanted to avoid this problem they would simply not specify a So instead of: responses:
200:
description: 'Notification successfully processed'
content:
text/plain:
examples:
ok:
value: 'ok' it would be: responses:
200:
description: 'Notification successfully processed' |
If you do not specify the content prism will also report an error that it couldn't match. Basically callbacks validation acts exactly the same as normal request validation. That points to a possible problem which I also noticed doing more or less the same as you are doing with |
@StefanDywersant You're correct, there might be a little bug in the Let's keep this separate though. I'll investigate into this — in meantime I would just change the error message from a generic thing to something more like "I received THIS and instead this is what's available in the document" |
@StefanDywersant ahh well this just shows that my next job of "play with proxy server and contract testing to make sure it works as expected" should have been done sooner. My bad. If the API does not specify content, then anything which comes in is a bonus, maybe a warning or an info, but certainly not an error. It's the sort of thing we'd report to folks via Studio somehow (long way off) saying "Hey we found some content, looks like this is JSON, here is the schema. Wanna save that to your description?" etc. How do I make a callback which says "I dont care what they respond with im just looking for a 200? A lot of callbacks work this way, they just want a "Yep!" and nothing more. |
@XVincentX just submitted an issue for that #774 |
@StefanDywersant sorry yeah, I didnt see his comment on this crap ferry wifi. Our comments passed each other like ships in the night. If you do the thing he suggested I've got a thumb ready and waiting! |
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.
🚀
Done in a22024a |
Closes #331
Checklist
What kind of change does this PR introduce?
feature
What is the current behavior? What is the new behavior?
This PR introduces Callback support in Prism (issue #331).
Does this PR introduce a breaking change?
No
Dependencies (needed to be merged first)