Isolate each newtab feed's onAction so one feed's error cannot withhold an action from the others
Categories
(Firefox :: New Tab Page, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox158 | --- | fixed |
People
(Reporter: florian, Assigned: florian)
References
(Blocks 1 open bug)
Details
Attachments
(1 external file)
Store._middleware dispatches each action to every registered feed in a bare loop, so a feed whose synchronous onAction throws ends the loop: the action never reaches the feeds registered after it, and the throw unwinds into whoever dispatched it. At startup that is silent and total -- a throw on PREFS_INITIAL_VALUES leaves PrefsFeed.init half-done, INIT never delivered, and one console.error from the try/catch around activityStream.init() in AboutNewTab.onBrowserReady as the only trace.
No feed throws there today, so this is a hazard rather than a failure, and the hazard is that the isolation is accidental: a feed whose onAction is async is isolated only because its throw becomes a rejection the loop never sees, and nothing tells a feed author which side they are on. Bug 2067207 is the near miss -- a train-hopped XPI recording a metric its host's Glean registry lacks, which happened to land on the async side.
Give each feed its own try/catch inside the loop, logging the feed name and the action type, the way EventEmitter._emit does for DevTools listeners ("Prevent a bad listener from interfering with the others").
|
Assignee | |
Comment 1•1 month ago
|
||
Store's middleware dispatches each action to every feed in a bare loop, so a
synchronous onAction that throws ends the loop: the later feeds never see the
action, and the throw unwinds into whoever dispatched it.
|
||
Updated•1 month ago
|
|
||
Comment 3•1 month ago
|
||
| bugherder | ||
|
||
Updated•1 month ago
|
Description
•