Skip to content

fix(resource-timing): prevent feedback loop by adding ignoreUrls#248

Open
mquentin wants to merge 4 commits intoopen-telemetry:mainfrom
mquentin:maxime.quentin/fix-sandbox-auto-instrument-loop
Open

fix(resource-timing): prevent feedback loop by adding ignoreUrls#248
mquentin wants to merge 4 commits intoopen-telemetry:mainfrom
mquentin:maxime.quentin/fix-sandbox-auto-instrument-loop

Conversation

@mquentin
Copy link
Copy Markdown
Contributor

Which problem is this PR solving?

The resource timing instrumentation does not have ignored URL API like the other core instrumentation (cf. XMLHttpRequestInstrumentation, FetchInstrumentation)

As a result, when the SDK post the signals to intakes, it is caught as a resource which has a timing which create a new signal to post to intake...

This PR adds an ignoreURL API to the ResourceTimingInstrumentation implemented like the XMLHttpRequestInstrumentation one.

I also configure this existing API for XMLHttpRequestInstrumentation, FetchInstrumentation and this new API for ResourceTimingInstrumentation in the Sandbox env to prevent infinite loop to happens.

Before

Screen.Recording.2026-04-27.at.08.42.17.mov

### After

Screen.Recording.2026-04-27.at.08.41.03.mov

Short description of the changes

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

  • Test A

Checklist:

  • Followed the style guidelines of this project
  • Unit tests have been added
  • Documentation has been updated

@mquentin mquentin changed the title bug(fix): address the issue of the auto resource timing instrumentation fix: address the issue of the auto resource timing instrumentation Apr 27, 2026
@mquentin mquentin changed the title fix: address the issue of the auto resource timing instrumentation fix: Address the issue with the automatic resource timing instrumentation Apr 27, 2026
@mquentin mquentin changed the title fix: Address the issue with the automatic resource timing instrumentation fix: Address the issue with the infinite loop of the self resource timing instrumentation Apr 27, 2026
@mquentin mquentin marked this pull request as ready for review April 27, 2026 07:06
@mquentin mquentin requested a review from a team as a code owner April 27, 2026 07:06
@mquentin mquentin changed the title fix: Address the issue with the infinite loop of the self resource timing instrumentation fix: address the issue with the infinite loop of the self resource timing instrumentation Apr 29, 2026
@overbalance overbalance changed the title fix: address the issue with the infinite loop of the self resource timing instrumentation fix(resource-timing): prevent feedback loop by adding ignoreUrls May 5, 2026
Comment on lines 176 to +180
} catch {
this._diag.warn(
'PerformanceObserver not supported, resource timings will not be collected',
);
this._observer = undefined;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Since this is narrowed, consider making it more specific:

Suggested change
} catch {
this._diag.warn(
'PerformanceObserver not supported, resource timings will not be collected',
);
this._observer = undefined;
} catch (e) {
this._diag.warn(
'Failed to start resource PerformanceObserver', e
);
this._observer = undefined;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We could also log the actual error (using the diagnostics logger).


/**
* URLs to ignore. Entries whose URL matches any of the patterns will not be
* captured. Strings are matched exactly; RegExps are tested against the full URL.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
* captured. Strings are matched exactly; RegExps are tested against the full URL.
* captured. Strings are matched exactly; RegExps are matched against the full URL.

/**
* URLs to ignore. Entries whose URL matches any of the patterns will not be
* captured. Strings are matched exactly; RegExps are tested against the full URL.
* Avoid RegExps with the `g` or `y` flag — their stateful `lastIndex` causes
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think y here causes alternating matches, but not g


/**
* URLs to ignore. Entries whose URL matches any of the patterns will not be
* captured. Strings are matched exactly; RegExps are tested against the full URL.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This says "matched exactly" but I think we should be a bit louder. Because OTel uses a strict equality, this is case-sensitive and not normalized so a trailing slash or query string reintroduces the loop.

Maybe suggest an example like[/\/v1\/traces$/, /\/v1\/logs$/] at the bottom.

this._flush();
}
this._pendingEntries.push(entry);
if (isUrlIgnored(entry.name, this._config.ignoreUrls)) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If this throws because of a bad regex, then the instrumentation does not recover - _scheduleProcessing is never called, and also no log that this has happened. I would either wrap the isUrlIgnored in try/catch or at least log an error.

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.

3 participants