Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

RUM drops XHR resources when two requests with the same method start in the same millisecond (resource key collision)

已关闭 适合新手
  • 哪里不对？
#1,497 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

@marco-saia-datadog 已经在做这个了。

开始于 2026年10月19日。

  • #1505 来自 @marco-saia-datadog —— 已合并

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
85/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
react-native, typescript
领域
observability-sre

调研方向

检查 packages/core/src/rum/instrumentation/resourceTracking/requestProxy/XHRProxy/XHRProxy.ts 中的密钥生成和 resource 报告机制。跟踪 proxyOpen 和 reportXhr，然后让每个打开的 XHR 都携带唯一的 resource 标识符，使使用相同方法的并发请求获得不同的 RUM 密钥。使用现有的 XHRProxy 测试或专门的复现用例进行验证，确认同一毫秒内的所有并行请求都被报告。

由索引模型根据 Issue 内容生成。

描述

bug
Describe the bug

XHRProxy builds the RUM resource key from the start timestamp (millisecond precision) and the HTTP method only:

// packages/core/src/rum/instrumentation/resourceTracking/requestProxy/XHRProxy/XHRProxy.ts
const key = `${context.timer.startTime}/${context.method}`;

ResourceReporter then calls DdRum.startResource(key, …) / DdRum.stopResource(key, …) with that key. When two requests with the same method start in the same millisecond, which is common when a screen fires a burst of parallel GETs, they get the same key. Only one of them ends up as a RUM resource; the other is silently dropped.

The same logic is still on develop (checked October 2026), so newer releases up to 3.10.0 appear to have it too.

Reproduction steps
  1. Fire several GET requests in parallel through XHR (axios here) when a screen mounts. Some of them start in the same millisecond.
  2. Compare the RUM resources for the session with an independent network capture: the backend logs, or a second RUM tool capturing the same requests.
  3. Requests that share a start millisecond and method with another request are missing from Datadog.
SDK logs

One session, Android, ~68 requests, compared against a second RUM SDK capturing the same requests. Datadog missed 4, and each one started in the same millisecond as another GET that Datadog kept:

Missing in Datadog Start (ms) Same-ms GET that was recorded
GET /eds/v2/???/<id> .937 GET /api/2.0/???
GET /api/4.0/???/history .682 GET /api/4.0/???
GET /???/api/v1/???/settings .683 GET /api/2.0/???
GET /api/2.0/???? .931 GET /api/2.0/???/.../???

All 4 returned 200 in 0.4–1.0s. Nothing filters them (no resourceEventMapper). The loss repeats across sessions, roughly 4–6% of requests on screens that load many endpoints at once.

Expected behavior

Every completed XHR is reported as its own RUM resource, however many requests start in the same millisecond.

Make the key unique per request, e.g. by adding a module-level counter (or a random ID) when the XHR is opened:

let resourceSequence = 0;
// in proxyOpen, store a unique id on _datadog_xhr:
this._datadog_xhr = { /* … */, resourceId: ++resourceSequence };
// in reportXhr:
const key = `${context.timer.startTime}/${context.method}/${context.resourceId}`;
Affected SDK versions

@datadog/mobile-react-navigation: 3.5.3

Latest working SDK version

@datadog/mobile-react-navigation: 3.5.3

Did you confirm if the latest SDK version fixes the bug?

Yes

Integration Methods

NPM

React Native Version
  • React Native 0.81.4, New Architecture (Fabric)
Package.json Contents
  • @datadog/mobile-react-navigation: 3.5.3
iOS Setup

No response

Android Setup

No response

Device Information
  • Android 16 (Samsung SM-S926B). Not yet verified on iOS, but the key logic is shared JS.
Other relevant information

No response

主要语言
TypeScript
星标
146
派生
67
平均合并
2 天 12 小时
30 天内合并 PR
23

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

DataDog/dd-sdk-reactnative 的其他 Issue

查看 DataDog/dd-sdk-reactnative 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。