- Adds the API endpoint and schema for analyze and analysis status.
- Adds `requestCreateAnalysis` and `requestAnalysisCreationStatus` methods for products.
- Updated `pollForAnalysisCompleted` to poll the analysis status api instead of analysis.
- Polling now has an initial wait of 30s and will poll every 1s after that for 3 more minutes when analyze status is pending.
- Polling will skip the wait and check every 1s (for 3 minutes) if analysis is already in progress.
- Removed exponential backoff as the new api gives updated progress with the status, so better to get it consistently.
- Removed links to external analysis triggers.
- Update ShoppingSidebarChild `updateContent` to check if there is an analysis in progress and if so wait for it to finish before requesting the analysis.
NOTE: Now that `pollForAnalysisCompleted` has a status api to poll, it returns a status result. The analysis data will now need to be requested with `requestAnalysis` after the polling has finished.
Differential Revision: https://phabricator.services.mozilla.com/D187818
Until now we updated origins frecency using direct SQL triggers.
While that guaranteed good performance, it also had some downsides:
* replacing the algorithms is complicate, the current system only works
with a straight sum of page frecencies. We are planning to experiment with
different algorithms in the future.
* it requires using multiple temp tables and DELETE triggers, that is error
prone for consumers, that may forget to DELETE from the temp tables, and thus
break data coherency.
* there's not much atomicity, since the origins update must be triggered apart
and a crash would lose some of the changes
This patch is changing the behavior to be closer to the recalc_frecency one that
is already used for pages.
When a page is added, visited, or removed, recalc_frecency of its origin is set
to 1. Later frecency of invalidated origins will be recalculated in chunks.
While this is surely less efficient than the existing system, it solves the
problems presented above.
A threshold is recalculated at each chunk, and stored in the moz_meta table.
This patch continues using the old STATS in the moz_meta table, to allow for
easier downgrades. Once a new threshold will be introduced we'll be able to
stop updating those.
The after delete temp table is maintained because there's no more efficient way
to remove orphan origins promptly. Thus, after a removal from moz_places,
consumers MUST still DELETE from the temp table to cleanup orphan origins.
This also introduces a delayed removal of orphan origins when their frecency
becomes 0.
Differential Revision: https://phabricator.services.mozilla.com/D186070
- Adds the API endpoint and schema for analyze and analysis status.
- Adds `requestCreateAnalysis` and `requestAnalysisCreationStatus` methods for products.
- Updated `pollForAnalysisCompleted` to poll the analysis status api instead of analysis.
- Polling now has an initial wait of 30s and will poll every 1s after that for 3 more minutes when analyze status is pending.
- Polling will skip the wait and check every 1s (for 3 minutes) if analysis is already in progress.
- Removed exponential backoff as the new api gives updated progress with the status, so better to get it consistently.
- Removed links to external analysis triggers.
- Update ShoppingSidebarChild `updateContent` to check if there is an analysis in progress and if so wait for it to finish before requesting the analysis.
NOTE: Now that `pollForAnalysisCompleted` has a status api to poll, it returns a status result. The analysis data will now need to be requested with `requestAnalysis` after the polling has finished.
Differential Revision: https://phabricator.services.mozilla.com/D187818
When a new url is passed in a `ShoppingSidebar:UpdateProductURL` message to a sidebar that already has a product assigned, this will check that the parsed product id of the new url is different than the previous product id before requesting a new analysis.
This should prevent reloading the data for the same product unnecessarily, for instance when only query params have changed.
Differential Revision: https://phabricator.services.mozilla.com/D187703
It isn't possible to manually test this right now until we set a cap in the
remote settings config (bug 1852353), but the automated tests cover it.
Depends on D187830
Differential Revision: https://phabricator.services.mozilla.com/D187835
The problem is that showing the dismissal acknowledgment tip does not remove the
result from the query context, so when the view later opens and reuses the
cached query context, it still has the dismissed result in it.
At first I thought I should modify `UrlbarView.acknowledgeDismissal()` so it
either invalidates the context cache or removes the result from the cached
context, but I saw that dismissals without the acknowledgment tip do not have
this problem. That's because they go through `UrlbarController.removeResult()`,
which removes the result from the context and then notifies the view.
The real problem is that I implemented dismissal acknowledgments wrong. They
should start by going through `UrlbarController.removeResult()` too.
This patch updates all callers of `acknowledgeDismissal()` so they call
`removeResult()` instead. To signal that an acknowledgment should be shown, they
first set a `result.acknowledgeDismissalL10n` property. When the view is
notified that a result was removed, it shows the tip if this property is
present.
Differential Revision: https://phabricator.services.mozilla.com/D187830
