Push notifications via unifiedpush don't work

[darhma]

Describe the bug
As per title push notifications via unifiedpush (using conversations/cheogram as provider/distributor) do not work.

To Reproduce
Steps to reproduce the behavior:
Enable conversations/cheogram as push notification provider

Expected behavior
You should receive push notifications

Screenshots

Smartphone (please complete the following information):

• Device: Pixel 7
• OS: GrapheneOS (Android 15)

Additional context

• App version: 0.7.4.sc16

• Store: F-Droid (official repo)

• Homeserver: tchncs.de

• Related experimental/labs settings:
  

• Logs have been submitted using the app's built-in bug report (/"rageshake") mechanism: no

Upstream relevance

• Does this issue exist in Element X Android? I didn't try
• If this issue exists in Element X Android, please also link the corresponding bug report (create a new one if it doesn't exist yet)

Add any other context about the problem here.
With the "classic" version of schildichat push notifications work, the problem occurs only with SchildiChat Next.
I use unifiedpush with mercurygram (a telegram client) without problems and testing them with the UP-Example app the notifications work.

[SpiritCroc]

element-hq/element-x-android#3571

[p1gp1g]

This is because of element-hq/element-x-android#3388 (as I mention here element-hq/element-x-android#3571 (comment)) and I don't really see why they always return the custom gateway

It would be nice to submit a patch, and ask why they did this. I can't do this patch atm.

I see one possible reason they would do that (broken) patch:

• If the application tests the custom gateway every time it receives a new endpoint, it may be possible a request to check the custom gateway timeout and they fallback to the default gateway but it shouldn't

If that's the case, then I think we can do this:

• If the check receives a 200: we use the custom, if the check returns a 404: we use the default one, else, we keep the old one if any (and fallback to the default)

[p1gp1g]

BTW, MSC4174 will help to get rid of this gateway. If someone wants to implement it for android, that'd be nice :)

[SpiritCroc]

I'd be happy to include a patch to fix this even if upstream takes longer to realize it's needed. Those commits that are to blame don't look like an easy git revert though so I didn't have the time to actually figure out how such patch should look in detail.

[p1gp1g]

I don't think the whole PR should be reverted. We just need to change libraries/pushproviders/unifiedpush/src/main/kotlin/io/element/android/libraries/pushproviders/unifiedpush/UnifiedPushGatewayResolver.kt to:

• return the customGateway if the check returns 200 and discoveryResponse.unifiedpush.gateway == "matrix"
• return the default gateway if the check returns 200 and there isn't discoveryResponse.unifiedpush.gateway == "matrix"
• return the default gateway if the check returns 404
• return the previous gateway if it fails
  • if there isn't a previous gateway, we can use one or the other, it doesn't really matter

[SpiritCroc]

Thanks! Yeah I don't think we should revert the whole thing. Maybe I can implement your suggestion later this week

[p1gp1g]

That'd be awesome, feel free to ping me (github or matrix) :)