Add ability to resubscribe an existing push channel

[rfk]

As a result of the discussions in #3314, I believe it may be possible for us to get into a situation where:

• A client device has a push subscription for FxA which it believes to be valid.
• The push server believes the subscription to be valid.
• The FxA server believes the subscription to be invalid.

I'm not sure how we get into such a state, but it fits with observed behaviours.

Assuming that the client finds itself in such a state, the only way it can repair things is to explicitly unsubscribe and then crate a new subscription to send to the FxA server. I think it would be useful to have a resubscribe abstraction of some sort to make thing easier.

@jonalmeida what do you think?

┆Issue is synchronized with this Jira Task
┆epic: Error detection and reduction

[jonalmeida]

This sounds like a fair solution with two clarifications:

• Should we be calling resubscribe after forcing registration renewal is complete or as a replacement for that?
• We could also implement this today at the AC layer. If so, I wonder if we should be calling subscribe only if unsubscribe fails. In code, would this if-statement seem necessary?

fun resubscribe(scope: String) {
  val result = appServicesPushManager.unsubscribe(scope)
  if (result) {
    subscribe(scope) { subscription -> accountManager.updatePushEndpoint(subscription) }
  }
}

A quick peek at communication.rs and it's usage shows that we only fail on communication exceptions, so we should be safe.

[rfk]

Should we be calling resubscribe after forcing registration renewal is complete or as a replacement for that?

I don't know to be honest. I wonder if "forcing registration renewal" should maybe even do an implicit resubscribe to all current push subscriptions, since the problem that's happening with FxA may also be happening elsewhere.

In code, would this if-statement seem necessary?

I think it should be fine to do without it if; indeed I can imagine circumstances under which we fail to unsubscribe because state has gotten out of sync between server and client, but re-subscribing will fix it.

[jonalmeida]

Merging the thread from a-c to here since the conversation there on a closed issue and may get lost. This issue is around the same area as well.

is this essentially the same as what's being discussed in #3696?

Yes, it's the same as this. For now, I've implemented the short-fix specifically for FxA only in order to get Send Tab working and unblock some other folks.

Actually, your comments in #3696 made me realize that an unsubscribe is likely to be necessary for this to work at all. The rust-component code for subscribe() will first check in its local store for an existing subscription before hitting the server, so unless something has occurred to clear that local state then it's always going to give back the same subscription URL.

I don't think we would need this outside of the scope of FxA afaict. For web content, we only notify the ServiceWorker that the subscription is no longer valid and let them decide if they want to subscribe again.

I don't know to be honest. I wonder if "forcing registration renewal" should maybe even do an implicit resubscribe to all current push subscriptions, since the problem that's happening with FxA may also be happening elsewhere.

That would be an interesting solution!

• We only do this force registration renewal call when we see the subscriptionExpired flipped, so my immediate fear tells me that, if we run into FxA specific bugs (like the one Re-subscribe only FxA push subscription when subscriptionExpired true mozilla-mobile/android-components#8846 is trying to fix) where the subscriptionExpired is always true, we may be telling everyone to update their subscription when they do not have issues.
• Web developers do not have the ability to perform a registration renewal, so it would be nice if we could solve this by simply re-subscribing as they would.

Would it be prudent in that case to assume those web apps will perform their own checks to ensure push support still works for them? Surely, we would also be getting bug reports from web developers more often if messages no longer were delivered. I'm not aware of the Fennec ones at least. Ha, reading this article tells me that they expect browser push services to notify on invalid subscriptions!

I think if we can rely on verify_connection to tell subscribers which subscriptions have been changed when endpoints are invalid, this should be covering the case of communication between the device and AutoPush servers and we only need to call "subscribe" then.

---

A bit outside scope, but one piece of knowledge is how desktop implements the onSubscriptionChanged event and if we on mobile are doing the right thing by expecting it from verify_connection alone.

[mhammond]

I think this is done with recent patches:

• verify_connection will let us know if the server doesn't think the subscription exists.
• We now encourage consumers to attempt to subscribe regularly and the component will avoid hitting the server if our DB already records it.
• this document describes further improvements that includes us keeping track of what subscriptions we want to exist so the consumers don't need to force-resubscribe all the time, but the above means we work ok these days in practice