-
Notifications
You must be signed in to change notification settings - Fork 825
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(otlp-exporter-base): Add fetch sender for ServiceWorker environment #3542
base: main
Are you sure you want to change the base?
Conversation
|
255c6a3
to
f654e84
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3542 +/- ##
==========================================
- Coverage 92.42% 92.15% -0.27%
==========================================
Files 330 330
Lines 9520 9577 +57
Branches 2031 2048 +17
==========================================
+ Hits 8799 8826 +27
- Misses 721 751 +30
|
Oh? Another test fails in CI. |
@open-telemetry/javascript-approvers I confirmed all tests are passed locally and added more tests. BTW, How can I sign added commits by EasyCLA? I cannot find the way. |
not sure what you mean? EasyCLA doesn't add any commits |
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 generally good and I appreciate all the tests
} else if (typeof XMLHttpRequest === 'function') { | ||
this.sendMethod = 'xhr'; | ||
} else { | ||
this.sendMethod = 'fetch'; | ||
} |
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.
Is there a reason to prefer xhr over fetch? I'm not a browser expert so I'm not sure what the advatages are of one over another.
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.
In this PR, I just prefer xhr to keep full compatibility with the current implementation.
I think fetch
is better in modern browsers in general.
In addition, fetch may also be preferred over useBeacon
when keepalive fetch is supported.
https://docs.google.com/document/d/1iHJtFa3jOo5n9QXHb6Ok5nK8kavXSk2DrLoubPWi9ys/edit
However, this PR is focused on just enabling opentelemetry-js work in a service/web worker environment.
I'll make a change to the order if you'd like to use fetch
by default.
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.
Deno and Cloudflare Workerd dont' support xhr inherently too. Only fetch is available on those platforms. Feature detection is a good choice to support those platforms.
However, I've been thinking that we may need to add a common internal http client that can be shared across exporters -- like the zipkin exporter. Also, adding a new base http implementation currently requires dedicated work to support features like retrying #3207.
I'd propose migrating this to be an internal tool and find a minimum http interface for exporters so that we can reduce the duplication across exporters: #3577.
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.
Oh. I agree with creating a new shared exporter is better.
I'm OK with any method if opentelemetry-js works in a worker environment.
So... should I ask you to determine whether to drop this PR or not?
@legendecas
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.
Sorry for the delayed response. I think this PR is still a good work and can be landed. #3577 updates more than OTLP exporters and needs more tailoring.
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.
I think "defaulting" to XHR as well rather than sendBeacon
(unless you know this is occurring during page unload -- which we dont' currently) is a better option as it is very possible that when the payload is larger than 64kb (or the total outstanding payload is > 64kb) you won't be able to send anything.
Which depending on whether there are or are not headers will occur (in the former case)
); | ||
} | ||
}) | ||
.catch((e: Error) => { |
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 catch block may also catch errors from the then
handler. I think possibly you meant to only catch errors from the fetch
itself? If so, I would move this error handler to be the second argument of then
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.
Oh, thank you.
I fixed it (7a36740)
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.
BTW, How can I sign added commits by EasyCLA? I cannot find the way.
not sure what you mean? EasyCLA doesn't add any commits
I'm worried it is OK that EasyCLA comments about only the first commit of this PR, or not.
#3542 (comment)
Anyway, I updated the review point.
); | ||
} | ||
}) | ||
.catch((e: Error) => { |
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.
Oh, thank you.
I fixed it (7a36740)
} else if (typeof XMLHttpRequest === 'function') { | ||
this.sendMethod = 'xhr'; | ||
} else { | ||
this.sendMethod = 'fetch'; | ||
} |
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.
In this PR, I just prefer xhr to keep full compatibility with the current implementation.
I think fetch
is better in modern browsers in general.
In addition, fetch may also be preferred over useBeacon
when keepalive fetch is supported.
https://docs.google.com/document/d/1iHJtFa3jOo5n9QXHb6Ok5nK8kavXSk2DrLoubPWi9ys/edit
However, this PR is focused on just enabling opentelemetry-js work in a service/web worker environment.
I'll make a change to the order if you'd like to use fetch
by default.
@sugi sorry for the slow cycle here this fell off my radar. I think for now you can go ahead with the PR and the unified http client can come as a later enhancement. |
@dyladan Thank you for your reply! I'm happy to hear that. So... What should I do next? |
Yes, merging the upstream master and then notifying sounds good. Thank you 🙂 |
@pichlermarc @dyladan Would you please review this again? |
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, however there's a lot of duplication in the implementation and tests that makes this PR very hard to review, and that I fear will make it even harder to maintain the exporters in the future.
If we want to merge this PR as it is now, we should immediately look into reducing duplication.
experimental/packages/exporter-trace-otlp-http/test/browser/CollectorTraceExporter.test.ts
Show resolved
Hide resolved
experimental/packages/exporter-trace-otlp-http/test/browser/CollectorTraceExporter.test.ts
Outdated
Show resolved
Hide resolved
experimental/packages/exporter-trace-otlp-http/test/browser/CollectorTraceExporter.test.ts
Outdated
Show resolved
Hide resolved
...ckages/opentelemetry-exporter-metrics-otlp-http/test/browser/CollectorMetricExporter.test.ts
Outdated
Show resolved
Hide resolved
experimental/packages/otlp-exporter-base/src/platform/browser/OTLPExporterBrowserBase.ts
Outdated
Show resolved
Hide resolved
@sugi any update? 🙂 |
@MSNev I has updated the branch with upstream |
Thank you for running workflows. And I'm sorry to forge to run lint fix. I updated files with |
@sugi do you have time to finish off the last few tests etc? |
Thank you for your mention! OK. I'll do tomorrow. |
I confirmed and reproduced the error on CI after merging the current upstream. I'm now fixing it... |
This is my misunderstanding. A merge miss caused my error. Anyway, I updated the branch against upstream and confirmed all tests and lints are passed on my local machine. I'm wondering if the test may fail on CI because I remember the tests of the previous push were also successful on my local machine. |
Oh..., the coverage test has failed. |
I added tests for BTW, I found some bugs in the original tests. All of the browser tests of
I skipped adding the test of |
Ouch. This point includes my mistake. Anyway, current tests for |
@sugi is this ready for review? If not please mark as draft |
@dyladan yes. please review. |
@dyladan what should I do next? |
@dyladan @legendecas @pichlermarc @MSNev could anyone please address this PR? I would be happy to assist with anything. We disabled logging in Manifest v3 extension, and would be happy to bring it back ASAP 🙏🏼 thanks |
We need it ASAP please merge |
We're working on refactoring transports for the OTLP exporters to ensure that we can maintain this feature (and other features) long-term. I'll let you know when we can move forward for this. I'm very sorry for the delay, but the exporters (and their tests) are not in shape for adding new features at this point in time. See #4631 (comment) and the issues liked therein. |
Do you have estimation for the time it will take? It is very important for us, we can see logs currently |
It is very hard to estimate how long things take in open-source land as it's very dependent on what else is going on in the repo. |
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days. |
Which problem is this PR solving?
The current implementation of OTLP exporter is not working in ServiceWorker of browsers, due to
XMLHttpRequest
andwindow
are not supported in the environment.This PR makes OTLP exporter works in the ServiceWorker.
Short description of the changes
fetch()
_globalThis
from the core library instead ofwindow
Type of change
How Has This Been Tested?
Checklist:
Documentation has been updated(skip: No breaking changes, no exported API, keep full compatibility)