Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash recovery #34

Open
mingyc opened this issue Sep 14, 2022 · 2 comments
Open

Crash recovery #34

mingyc opened this issue Sep 14, 2022 · 2 comments

Comments

@mingyc
Copy link
Collaborator

mingyc commented Sep 14, 2022

For browser crashes, forced app closures, etc, the browser should make an effort to send the beacons the next time it is launched (guarantees around privacy and reliability here will be the same as the Reporting API’s crash reporting).

Filing this issue to track relevant discussion

  1. This is blocked by privacy concern: [Privacy] Address privacy requirement around "network changes" #30
  2. Per discussion from TPAC meeting, even without 1, the usage of an outdated pending beacon recovered from, e.g. 24 hours ago, might be pretty limited in terms of analytics.
  3. Plus, user can already use local storage to achieve similar things without a new API.
mingyc added a commit that referenced this issue Sep 14, 2022
Update Privacy section to clarify why beacon needs to be stopped when network changes (#27 #28)

Also added links to related privacy discussions: #3, #27, #30, #34
Updated beacon TTL to 30min per suggestion in #16 (comment)
@mingyc mingyc changed the title Crash recovery from disk Crash recovery Sep 14, 2022
@fergald
Copy link
Collaborator

fergald commented Sep 21, 2022

I don't think "user can already use local storage to achieve similar things without a new API" is an argument against providing the capability because for a user to do it themselves. Instead that leaves a class of users that are unable to migrate to use the Beacon and may instead just stay writing complex code with IDB + fetch and maybe + beacons and/or maybe keeping unload handlers.

The use-case of perfect logging system does not have to be our goal but if we were to say that crash recovery only occurs when the site could have done it itself (i.e. the site or a worker for the site becomes active) then I don't see a problem with allowing the data to live for a long time (if the site chooses it). As long as we aren't adding new capabilities that sites didn't have before, we should not be opposed to it on principal.

@mreinstein
Copy link

Instead that leaves a class of users that are unable to migrate to use the Beacon and may instead just stay writing complex code with IDB + fetch and maybe + beacons and/or maybe keeping unload handlers.

I am definitely in that class of users, @fergald. I've tried multiple strategies to try to move to beacon transport, and measured each approach against the existing approach (spamming .gif requests) and the beacon method always comes up short. Especially when aggregating literally billions of user sessions. The difference is large enough that my peers/bosses won't accept that loss in the name of more efficient network usage.

I don't believe these are all crash scenarios either; I think in some cases the network legitimately goes away (e.g., user on a train goes into a tunnel) and the message never delivers. More deets if curious/interested: #40 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants