feat: add wgc request ID generation & propagation #1507
Conversation
ID is unique for each command execution.
turnabout
force-pushed
the
wgc-request-id
branch
from
88e5e4c to
0c8e74a
Compare
…orkspace (wundergraph#1502) Co-authored-by: Dustin Deus <[email protected]>
| } | ||
| }; | ||
|
|
||
| await requestIdInterceptor(() => ERR_RESPONSE)(req); |
There was a problem hiding this comment.
Do we really need mock tests, if we can test success and error case with a service implementation here? I'd always suggest real integration tests over spys or mocks. WDYT?
There was a problem hiding this comment.
I understand your point. The way I see it, this test is testing the interceptor in isolation (as much as possible) while the other is testing the complete feature. I usually like having both of these kinds of tests together, to give me the peace of mind an implementation works as expected by itself, but also in the context of a complete feature.
But I guess there is significant overlap here. If you think they're not needed or not aligned with the rest of the project, I can certainly remove them.
There was a problem hiding this comment.
Thanks for clarifying. I do a see a benefit of combining them. Please do 😊
There was a problem hiding this comment.
I removed the test file request-id-interceptor.test.ts and ported the two test cases that didn't overlap between them to request-header.test.ts (I assumed that's what you meant by "combining them"). The test cases are:
- 'Should log the request ID when the response errored'
- 'Should NOT log the request ID when the response was successful'
Removes `request-id-interceptor.test.ts` and ports test cases that dont' overlap to `request-header.test.ts`. Also updates `requestIdInterceptor` to output error message using `console.error`, to differentiate from other command `console.log` calls during tests
Motivation and Context
The
wgcCLI currently does not generate a unique identifier for each request made to the control plane. The goal is to generate one when executing a command, propagate it to the control plane (on all requests sent to it), and attach it to control plane logs for easier debugging.In the case of a control plane error during the execution, the request ID is printed to the user.
Checklist
wgcnode:cryptoand attaching to the global config once. This results in the same id being reused on all requests sent to the control panel by a commandrequestIdInterceptor), so the solution is reused in all subcommandsenrichLoggerto extract the request ID header (if it exists) and include it as additional log fields