You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently XHR and Fetch instrumentation are treating CORS with the assumption that there's 2 entries (one for the actual request, another for the preflight) on the performance entry.
This is not the case.
Steps to Reproduce
Launch the web-opentelemetry-example
Instrument a client with either XHR or fetch instrumentation
Expected Result
CORS preflight requests are created as child spans of the main request
For fetches composed of multiple requests (e.g. preflights, authentication challenge-response, redirects, and so on), the reported responseStart value is that of the last request.
Which means there's no duplicate entry performance entry in case of preflights.
OpenTelemetry Setup Code
const{ context, trace }=require('@opentelemetry/api');const{ ConsoleSpanExporter, SimpleSpanProcessor }=require('@opentelemetry/sdk-trace-base');const{ OTLPTraceExporter }=require('@opentelemetry/exporter-trace-otlp-http');const{ WebTracerProvider }=require('@opentelemetry/sdk-trace-web');const{ FetchInstrumentation }=require('@opentelemetry/instrumentation-fetch');const{ ZoneContextManager }=require('@opentelemetry/context-zone');const{ B3Propagator }=require('@opentelemetry/propagator-b3');const{ registerInstrumentations }=require('@opentelemetry/instrumentation');const{ Resource }=require('@opentelemetry/resources');const{SEMRESATTRS_SERVICE_NAME}=require('@opentelemetry/semantic-conventions');constprovider=newWebTracerProvider({resource: newResource({[SEMRESATTRS_SERVICE_NAME]: 'fetch-web-service'})});// Note: For production consider using the "BatchSpanProcessor" to reduce the number of requests// to your exporter. Using the SimpleSpanProcessor here as it sends the spans immediately to the// exporter without delayprovider.addSpanProcessor(newSimpleSpanProcessor(newConsoleSpanExporter()));provider.addSpanProcessor(newSimpleSpanProcessor(newOTLPTraceExporter()));provider.register({contextManager: newZoneContextManager(),propagator: newB3Propagator(),});registerInstrumentations({instrumentations: [newFetchInstrumentation({ignoreUrls: [/localhost:8090\/sockjs-node/],propagateTraceHeaderCorsUrls: ['https://cors-test.appspot.com/test','https://httpbin.org/get',],clearTimingResources: true,}),],});constwebTracerWithZone=provider.getTracer('example-tracer-web');constgetData=(url)=>fetch(url,{method: 'GET',headers: {Accept: 'application/json','Content-Type': 'application/json',},});// example of keeping track of context between async operationsconstprepareClickEvent=()=>{consturl='https://httpbin.org/get';constelement=document.getElementById('button1');constonClick=()=>{constsingleSpan=webTracerWithZone.startSpan('files-series-info');context.with(trace.setSpan(context.active(),singleSpan),()=>{getData(url).then((_data)=>{trace.getSpan(context.active()).addEvent('fetching-single-span-completed');singleSpan.end();});});for(leti=0,j=5;i<j;i+=1){constspan=webTracerWithZone.startSpan(`files-series-info-${i}`);context.with(trace.setSpan(context.active(),span),()=>{getData(url).then((_data)=>{trace.getSpan(context.active()).addEvent(`fetching-span-${i}-completed`);span.end();});});}};element.addEventListener('click',onClick);};window.addEventListener('load',prepareClickEvent);
It's not really clear what you mean here. In the issue you say "CORS preflight requests are created as child spans of the main request" but in the PR you introduced it looks like you're actually removing this behavior? Are you saying the behavior doesn't work and should be removed for that reason? Or are you saying we shouldn't be creating these spans at all?
Are you saying the behavior doesn't work and should be removed for that reason?
Thank you for the reply. Exactly.
The current code was built upon what seems a false assumption: that there's two Performance entries per each cross-origin request (one for the preflight/OPTIONS/CORS, another for the actual request).
There isn't. (Maybe this was the case in some early implementations of the Resource Timing spec?)
At least as per Resource Timing level 2, request preconditions (authentication, redirects, CORS) are accounted for as a part of the entry of the originator request.
There is no way of, with the PerformanceResourceTiming, extracting (or inferring) data for the CORS preflight request specifically.
Which means that we could drop this code entirely: needing to find the duplicate (there will never be one) and if there's one, using it to create a nested span.
What happened?
Currently XHR and Fetch instrumentation are treating CORS with the assumption that there's 2 entries (one for the actual request, another for the preflight) on the performance entry.
This is not the case.
Steps to Reproduce
web-opentelemetry-example
Expected Result
Actual Result
Additional Details
I believe this behaviour happens because according to Resource Timing Level 2:
Which means there's no duplicate entry performance entry in case of preflights.
OpenTelemetry Setup Code
package.json
Relevant log output
No response
The text was updated successfully, but these errors were encountered: