feat: Expire duplicate RPC requests after three minutes#24487
feat: Expire duplicate RPC requests after three minutes#24487
Conversation
There was a problem hiding this comment.
I picked five minutes because it seems extremely unlikely that we'd receive an actually duplicate request id in that timespan. Curious if we could go with an even shorter timespan, but I would need guidance from someone more familiar with MV3.
Builds ready [9685326]
Page Load Metrics (1056 ± 647 ms)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #24487 +/- ##
===========================================
+ Coverage 67.38% 67.46% +0.08%
===========================================
Files 1289 1289
Lines 50235 50263 +28
Branches 13008 13024 +16
===========================================
+ Hits 33849 33906 +57
+ Misses 16386 16357 -29 ☔ View full report in Codecov by Sentry. |
|
Can the typescript conversion be split out in a separate PR, preceding the rest of the changes in this one? |
9685326 to
2483ec7
Compare
Builds ready [2483ec7]
Page Load Metrics (951 ± 579 ms)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Builds ready [861e299]
Page Load Metrics (1311 ± 540 ms)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
|
Missing release label release-11.16.6 on PR. Adding release label release-11.16.6 on PR and removing other release labels(release-11.18.0), as PR was cherry-picked in branch 11.16.6. |
Description
Flushes the memorized request ids in the duplicate request middleware every 3 minutes, and makes the middleware ignore JSON-RPC notifications. Also converts the middleware to TypeScript.
The duplicate request middleware used to dedupe JSON-RPC requests with the same id under MV3 used an internal array that would grow boundlessly until the background restarted. In addition, this middleware assumed that it would never see any JSON-RPC notifications (or it would always reject the
n + 1:th notifications, since their ids are alwaysundefined). Although we in practice always add ids to JSON-RPC requests, it seems ill-advised for this middleware to make that assumption.Related issues
N/A
Manual testing steps
Pre-merge author checklist
Pre-merge reviewer checklist