Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Talk push: server sends priority high, Android receives no FCM priority and test pushes arrive 7–8 min late

Aperta
  • Qualcosa non va?
#3,464 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
android, firebase, javascript
Ambito
backend

Direzione di ricerca

Start by reading lib/Push.php around getNotifTopicAndUrgency() (lines 966–975) and encryptAndSign(); compare the outgoing priority/type fields with the device observations in the issue. The proxy source is not public, so the issue leaves the mapping and cause unresolved. Done means identifying whether this app sends the expected FCM priority and explaining the delayed test pushes, likely requiring further client logs or proxy-side investigation.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Talk pushes sent by the server with priority: high arrive on Android with no FCM priority set. Some test pushes reach the device 7–8 minutes late. Without a high-priority FCM message, Android does not give the backgrounded Talk app network access, so the app cannot fetch the notification from the server while the screen is off.

Setup
  • Two servers: Nextcloud 35.0.1, notifications 8.0.0, spreed 25.0.5 and 25.0.2.
  • Push proxy: the shared https://push-notifications.nextcloud.com. Device registration succeeds on both servers.
  • Client: Talk Android (gplay flavor, test build from master plus diagnostics), Android 12 (API 31). Battery optimization is off. Data Saver is off.
What the server sends (from code)

lib/Push.php:966-975 (getNotifTopicAndUrgency()) sets priority: high for the apps spreed, talk and admin_notification_talk. It sets type: alert for chat and voip for calls. encryptAndSign() puts priority and type into the request to the proxy. Delete pushes are sent as normal / background (:1055-1057). No app config changes this.

What the device receives

The client logs RemoteMessage.getPriority() and getOriginalPriority() in onMessageReceived. Two observations:

  1. Every message has priority=0 and originalPriority=0 (PRIORITY_UNKNOWN). This includes chat pushes (high on the server), delete pushes (normal), and messages that arrive while the app is in the foreground. The client cannot tell high from normal.
  2. occ notification:test-push --talk <user> ran at 13:43:10 UTC on one server and 13:44:11 UTC on the other (two pushes). All three messages reached the device together at 13:51:12 UTC (sentTime → receipt: 421–481 s). Regular chat pushes during the same period, screen off, arrived in under 1 s.

At every receipt with the screen off, the app had no network: activeNetwork=false, NetworkInfo.DetailedState=BLOCKED, deviceIdle=false, restrictBackground=1.

Questions
  1. How does the proxy map the priority / type fields of the request to the FCM message (android.priority, ttl, data vs. notification message)?
  2. Should RemoteMessage.getOriginalPriority() report HIGH for Talk chat pushes? If yes, where is it lost?
  3. Is the 7–8 minute delay of the test pushes expected (for example, a different type or priority for admin_notification_talk)?

The proxy source is not public, so we cannot check this ourselves. We can provide more client logs.

AI disclosure

This issue was written with help from an AI assistant (Claude). The data comes from our server code reading, server occ output and device logs, and was reviewed by me.

Lingua principale
JavaScript
Stelle
156
Fork
69
Merge medio
17h 14m
PR unite (30g)
89

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nextcloud/notifications

Tutte le issue di nextcloud/notifications

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.