f5a4fb1b35
This reverts commit ce4d63c12d.
Reason for revert: build failure on android-desktop-x64-archive-rel
ERROR at //extensions/browser/api/messaging/BUILD.gn:7:1: Assertion failed.
assert(enable_extensions,
^-----
Cannot depend on extensions because enable_extensions=false.
See //extensions/BUILD.gn:297:5: which caused the file to be included.
"//extensions/browser/api/messaging:unit_tests",
^----------------------------------------------
Original change's description:
> [Extensions] Create message delivery tracker class.
>
> Message delivery appears to be failing in some stages of the message
> process because sometimes the caller never gets a response from the
> background context (specifically service workers). To scope down where
> in the process the issue might be occurring I created this class to
> help coordinate the tracking of the message.
>
> The tracker will monitor message progress through key stages and emits
> success/failure metrics. This will help pinpoint potential issues in
> the message delivery process.
>
> It allows a caller (in the browser) to call this singleton as the
> message is observed to pass through each stage.
>
> It is not specific to workers to allow for comparison between
> background types.
>
> The general flow of a call is:
> 1) NotifyStartTrackingMessageDelivery() to start tracking a message
> to its background context
> 2) NotifyUpdateMessageDelivery() each time when the next stage in
> message delivery has been reached
> 3) NotifyStopTrackingMessageDelivery() to stop tracking the message
> when it has been deemed as *successfully delivered to the
> background context (which emits success metrics)
>
> Starting and updating message delivery will result in a delayed task
> (NotifyStaleMessage()) that is called 30 seconds later. 30 seconds was
> determined arbitrarily. If the message is still being tracked at this
> point it is considered stale/unsuccessful and failure metrics will be
> emitted.
>
> *Successful can be defined differently depending on if the caller
> expects a response or not since expecting a response would track the
> later response stages back to the caller, whereas not expecting a
> response wouldn't need to track those later stages.
>
> Bug: 371011217
> Change-Id: I1d02837fb6dcccec3a56fb4cc6b1a5974087a180
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5906729
> Auto-Submit: Justin Lulejian <jlulejian@chromium.org>
> Reviewed-by: Emilia Paz <emiliapaz@chromium.org>
> Commit-Queue: Justin Lulejian <jlulejian@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1366516}
Bug: 371011217
Change-Id: I01ea44beb79de8aec8efc181684dda9e130af0f5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5921259
Commit-Queue: Liza Bipin <mlbipin@google.com>
Owners-Override: Liza Bipin <mlbipin@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Liza Bipin <mlbipin@google.com>
Cr-Commit-Position: refs/heads/main@{#1366677}
This will become a reusable extensions module. It implements the core parts of Chrome's extension system, and can be used with any host of the content module.
Some extensions code that is not Chrome-specific still lives in //chrome/browser/extensions and will be moved here.
Technical Documentation: