-
Notifications
You must be signed in to change notification settings - Fork 443
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
feat(cli): Take request headers, params, and body into account when saving responses #3098
base: master
Are you sure you want to change the base?
Conversation
Will test this out tomorrow. One thing I think we should handle is how to either migrate or have backwards compat for existing mock files. |
@khaliqgant Well and I'd say hold off on digging into this too much because my testing proposal would supersede this anyway. |
It's cleaner for ordering
@khaliqgant OK, did some final cleanup on this based on our prior discussion. Marking this ready for review from you and then if you're cool with it I'll pass on to the rest of the eng team. |
} | ||
} | ||
|
||
if (dataString.length > 1000) { |
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.
why not always hashing?
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.
It's easier to spot why things changed in the recorded payloads if you dump the literal payload, rather than just a hash, but when the payloads get extremely large it's not really reasonable to store them anymore.
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.
Works well. See feedback around headers. Preferably the connection-id and provider-config-key are filtered out
const url = new URL(config.url!); | ||
const endpoint = url.pathname.replace(/^\/proxy\//, ''); | ||
|
||
const requestIdentity: [string, unknown][] = [ |
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.
@TBonnin @khaliqgant I had to add some new logic in here to compute endpoint
as best I could and use that since in the test env we don't have a full URL to match against.
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.
Looks good, but blocked on merging right?
@khaliqgant Yeah, I'd say let's get the zoom PR in and then get the updated tests PR in on integrations and then merge this one last so we're not breaking integration engineers in the meantime. |
Important: This should merge after an as-yet non-existent change in integration-templates.
When running the cli with --save-responses we currently only take the method and url into account. This PR adds support for recording the response with a request identity into a hash based file.
It currently does not support Stream based request bodies (
data
).One major downside of this technique is that the hash based filenames aren't the easiest to read. That said, the data in the files makes it pretty straightforward to see what's going on.
See https://linear.app/nango/issue/NAN-1902/fix-integration-unit-test-pagination
How I tested it
nango
repo works inintegration-templates
Format
Here's how the resulting cached requests look. They're definitely not perfect yet, but give us enough to improve our tests.
Note: There are recordings of me staring at my camera trying to generate enough recordings to get the Zoom API to paginate here. Great videos!
Example cached file