-
Notifications
You must be signed in to change notification settings - Fork 156
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
Fetch #590
Fetch #590
Conversation
…all to createSqlData to send those values from the arguments made to the sql call
packages/core/package.json
Outdated
@@ -1,6 +1,6 @@ | |||
{ | |||
"name": "aws-xray-sdk-core", | |||
"version": "3.5.0", | |||
"version": "3.4.1", |
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.
This corresponds to the current release version (3.5.0) and should never be changed to a prior version - this version number is only modified by the X-Ray team when preparing a new release. I imagine this is what is causing most of the CI failures.
To fix this, please keep this version as is - 3.5.0. We have an sdk_contrib directory that houses all community contributed instrumentations, so it would be great if this instrumentation could be moved there.
Also thought it would be worth mentioning since we do not usually maintain instrumentations in sdk_contrib, would you be willing to maintain it going forward and keep track of any issues that come in?
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.
Q: Do you want to create a patchers
directory in sdk_contrib for this, since all of the existing contributions are all middleware hooks?
package.json
Outdated
@@ -21,6 +21,7 @@ | |||
"aws-xray-sdk-core": "3.5.0", | |||
"aws-xray-sdk-express": "3.5.0", | |||
"chai": "^4.2.0", | |||
"chai-as-promised": "^7.1.1", |
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.
Following up to the comment on moving to sdk_contrib, the dependencies that are unique to this instrumentation would then be placed in the package.json of the new instrumentation package in sdk_contrib.
You can reference this fastify instrumentation PR as a guide to help
* This module patches the global fetch instance for NodeJS 18+ | ||
*/ | ||
|
||
var contextUtils = require('../context_utils'); |
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.
nit: use const instead of var
packages/core/package.json
Outdated
"mocha": "^10.2.0", | ||
"semver": "^5.3.0", | ||
"tsd": "^0.28.1", | ||
"typescript": "^5.0.4" |
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.
mocha, tsd, and typescript are not needed here since they get pulled from the root package.json
Hi, my wife and I are on vacation for our 25th anniversary. I had to leave the computer at home lol. I will be able to knock these out at the end of the month, sorry for the delay. |
…ou really need it to cleanly test async with chai; also fixed some lint findings
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #590 +/- ##
=======================================
Coverage 83.49% 83.49%
=======================================
Files 37 37
Lines 1805 1805
=======================================
Hits 1507 1507
Misses 298 298 ☔ View full report in Codecov by Sentry. |
I'm going to try and resurrect this. Let me know if this seems feasible or if I should abandon. Thanks! |
Hi, can you address @carolabadeer's comment: |
Done and committed. |
You may have addressed the comment below the comment I linked.
Was this file intended to be removed when you moved your contributions to |
Committed removal of chai-as-promised and tsconfig.debug.json |
Can you look into the failing tests? There seems to be an issue with All similar:
|
Thanks, just a few more small changes in addition to the new comments. A previous request was to remove Also please remove the following files
|
Ugh... I'll have to look at the tests failing after the updated npm test script later tonight |
I believe this line is failing: |
Yeah, releasing "export for resolveManualSegmentParams" would be the more proper way of addressing this issue. The riskier and less ideal workaround would be to merge+release your PR, then hope that the |
I've gone ahead and put in a PR to add the resolveManualSegementParams export. If this is the way we need to go on this, I can wait until this is "live" before picking the fetch merge back up.
On Wednesday, January 24, 2024 at 03:06:35 PM CST, Jonathan Lee ***@***.***> wrote:
Do we need to release that first before it's available for use by sdk_contrib, or is there some "trick" I can do in package.json to make this work?
Yeah, releasing "export for resolveManualSegmentParams" would be the more proper way of addressing this issue. The riskier and less ideal workaround would be to merge+release your PR, then hope that the Continuous Build Github Workflows will pass after the new release. We'll see if there's a better alternative.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
@jasonterando I looked into the segment generated by this PR, and I noticed that the Fetch Response information was missing in the segment.
I saw that this is because the See how it is done for HTTP:
Do you have bandwidth anytime to implement extracting Fetch request/response data into subsegment and corresponding unit tests? Otherwise I could take a stab at it later. |
@jj22ee - yeah I can take a look at it, probably not until the weekend though, day job is hectic. Should I work from fetch-pr? |
You can still work from this PR's |
Hi, just committed updates that write to subsegment.http. One thing that wasn't clear was how traced is supposed to work. It looks like RemoteRequestData.init sets request.traced to true if downstreamXRayEnabled) is true, but then traced gets subsequently moved to the subsegment in addRemoteRequestData. In my code, I'm just setting subsegment.traced to true if downstreamXRayEnabled is true. If that's wrong, and I need to do the "two-step", let me know. |
Subsegment.prototype.addFetchRequestData = function addFetchRequestData(request, response, downstreamXRayEnabled) { | ||
this.http = { | ||
request: { | ||
url: request.url.toString(), |
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.
url: request.url.toString(), | |
url: (request.url) ? request.url.toString() : '', |
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.
Ok, done. I also put in a non-set check for method. .d.ts file is added for Subsegment.addFetchRequestData
Thanks for adding |
…r method are not set store '' in http data
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.
LGTM!
TYSM for the contribution @jasonterando! |
Thanks a lot @jasonterando for the effort and @jj22ee for the review. Truly appreciate the merge ❤️ |
Issue #, if available: 585
Description of changes: Add fetch patch, including support for built-in fetch API for NodeJS current versions and node-fetch for older NodeJS versions.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.