Skip to content
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

fix: refactoring and solves #2321 #2380

Closed
wants to merge 2 commits into from

Conversation

niko-achilles
Copy link
Contributor

@niko-achilles niko-achilles commented Jul 27, 2021

Which problem is this PR solving?

Short description of the changes

  • blob type as header is send with beacon
  • user has the ability to set the blobType in collectorConfiguration
  • after looking at the codebase , i think that the utils.ts should not have logic behavior for correcting the headers, given in the code base , the CollectorExporterBrowserBase knows about headers and logic

@codecov
Copy link

codecov bot commented Jul 27, 2021

Codecov Report

Merging #2380 (9afe781) into main (e089984) will decrease coverage by 0.02%.
The diff coverage is n/a.

❗ Current head 9afe781 differs from pull request most recent head 73c873b. Consider uploading reports for the commit 73c873b to get more accurate results

@@            Coverage Diff             @@
##             main    #2380      +/-   ##
==========================================
- Coverage   92.36%   92.34%   -0.03%     
==========================================
  Files         128      128              
  Lines        4244     4244              
  Branches      867      867              
==========================================
- Hits         3920     3919       -1     
- Misses        324      325       +1     
Impacted Files Coverage Δ
...emetry-core/src/platform/node/RandomIdGenerator.ts 87.50% <0.00%> (-6.25%) ⬇️

@niko-achilles niko-achilles marked this pull request as draft July 27, 2021 23:00
@niko-achilles
Copy link
Contributor Author

niko-achilles commented Jul 29, 2021

saved as draft until a result merge output from #2336

in short this commit has tests that pass

CollectorTraceExporter - web

when "sendBeacon" is available
  • and user defines headers
    ✓ should successfully send user defined headers using XMLHttpRequest
    ✓ Request Headers should contain "Content-Type" header
    ✓ Request Headers should contain "Accept" header

  • and user does not define headers
    ✓ should successfully send the spans using sendBeacon
    ✓ should successfully send expected blob type using sendBeacon

  • and user sets headers as undefined
    ✓ should successfully send the spans using sendBeacon
    ✓ should successfully send expected blob type using sendBeacon

  • and user defines blob type
    ✓ should successfully send the spans using sendBeacon
    ✓ should successfully send user defined blob type using sendBeacon

  • and user does not define blob type
    ✓ should successfully send the spans using sendBeacon
    ✓ should successfully send expected blob type using sendBeacon

  • and user defines blob type as undefined
    ✓ should successfully send the spans using sendBeacon
    ✓ should successfully send expected blob type using sendBeacon

  • should be able to handle logs
    ✓ when successful with can-send message
    ✓ when errored with cannot send message

when "sendBeacon" is NOT available
  • and user defines headers
    ✓ Request Headers should contain user defined headers
    ✓ Request Headers should contain "Content-Type" header
    ✓ Request Headers should contain "Accept" header

  • and user does not define headers
    ✓ should successfully send the spans using XMLHttpRequest
    ✓ Request Headers should contain "Content-Type" header
    ✓ Request Headers should contain "Accept" header

  • and user sets headers as undefined
    ✓ should successfully send the spans using XMLHttpRequest
    ✓ Request Headers should contain "Content-Type" header
    ✓ Request Headers should contain "Accept" header

  • and user defines blob type
    ✓ should successfully send the spans using XMLHttpRequest
    ✓ Request Headers should contain "Content-Type" header
    ✓ Request Headers should contain "Accept" header

  • and user does not define blob type
    ✓ should successfully send the spans using XMLHttpRequest
    ✓ Request Headers should contain "Content-Type" header
    ✓ Request Headers should contain "Accept" header

  • and user defines blob type as undefined
    ✓ should successfully send the spans using XMLHttpRequest
    ✓ Request Headers should contain "Content-Type" header
    ✓ Request Headers should contain "Accept" header

  • should be able to handle logs
    ✓ should log the successful message
    ✓ should log the error message

CollectorMetricExporter - web

when "sendBeacon" is available
  • ✓ should successfully send metrics using sendBeacon

  • ✓ should successfully send blob type using sendBeacon

  • ... tests cases can be extended with further tests in context of review ....

@dyladan
Copy link
Member

dyladan commented Aug 2, 2021

Before you take this PR out of draft status please give it a meaningful name. The PR name goes into the git log as the main message when the PR is squashed and having to refer to an external issue to learn its meaning is a frustrating workflow.

@@ -33,6 +33,12 @@ export abstract class CollectorExporterBrowserBase<
ExportItem,
ServiceRequest
> {
private DEFAULT_HEADERS = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do you think it's better to keep defaults on instance instead in utils ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct me if i am wrong.

Who owns the config ?

  • The CollectorExporterBrowserBase
  • Owning the data means working with the data and correcting the data if needed, like applying default headers or type for blob property bag.

What are the methods sendWithXhr, sendWithBeacon under
opentelemetry-js/packages/opentelemetry-exporter-collector/src/platform/browser/util.ts ?

  • Are roles with the responsibility to send data with a protocol.
  • Protocol is the name of each function and data is the arguments that each function define.

Accept: 'application/json',
'Content-Type': 'application/json',
};
private DEFAULT_BLOB_TYPE = { type: 'application/json' };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imho it should not be a part of CollectorExporterBrowserBase.ts as it is only used if beacon is used -> move to util

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the logic deciding if beacon is used , is a decision that CollectorExporterBase already has made before sendWithBeacon util function.

{},
parseHeaders(config.headers),
baggageUtils.parseKeyPairsIntoRecord(
this._headers = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to have 2 util functions

  • prepareXHRHeaders / getXHRHeaders / parseXHRHeaders etc.
  • prepareBeaconHeaders ...

Currently the logic will be scattered between util and exporter, where exporter should not contain anymore logic then it is necessary and those functions will be straightforward and easy to understand. If someone want to change it you will change util class not the exporter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually i think that the correct place would be to put the utility functions like the ones you mention here under
https://github.com/open-telemetry/opentelemetry-js/blob/main/packages/opentelemetry-exporter-collector/src/util.ts

What do you think ?
My motivation is because in this file there is already a helper method parseheaders.
https://github.com/open-telemetry/opentelemetry-js/blob/main/packages/opentelemetry-exporter-collector/src/util.ts#L23

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or a better one, what do you think ?

rename the file util to send under https://github.com/open-telemetry/opentelemetry-js/blob/main/packages/opentelemetry-exporter-collector/src/platform/browser/util.ts
and export from it the functions sendWithXhr, sendWithBeacon.

Then introduce a util.ts under opentelemetry-js/blob/main/packages/opentelemetry-exporter-collector/src/platform/browser/
with the functions as helpers you mentioned above

  • prepareXHRHeaders / getXHRHeaders / parseXHRHeaders etc.
  • prepareBeaconHeaders ...

Then send module and util module can be imported to CollectorExporterBase and collector exporter base can work with them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@obecny a more consistent solution is given by @MSNev in context of blob and sendWithBeacon here:
#2336 (comment)

So can i move the default header for xhr inside the send method of CollectorExporterBase ?
i mean this logic under util.ts
https://github.com/open-telemetry/opentelemetry-js/blob/main/packages/opentelemetry-exporter-collector/src/platform/browser/util.ts#L59

to send method here:
https://github.com/open-telemetry/opentelemetry-js/blob/main/packages/opentelemetry-exporter-collector/src/platform/browser/CollectorExporterBrowserBase.ts#L94

it should then look something like this:

if(this.xhr){
const headers = {...{"Content-Type":"application/json", "Accept": "application/json"},...this.headers}
sendWithXhr(body, this.url, headers, _onSuccess, _onError);
}

i would then close this PR and open a new one in order to be in context of xhr only , given the blob context PR will be handled here: #2336

@obecny , @MSNev, what do you think for the above refactoring proposal for xhr ?

@Flarna Flarna changed the title fix: refacrtoring and solves #2321 fix: refactoring and solves #2321 Aug 4, 2021
@niko-achilles
Copy link
Contributor Author

closing this PR because of #2336

@niko-achilles niko-achilles deleted the useBeacon branch August 10, 2021 12:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Traces send by http protocol fail in new Otel collector receiver
3 participants