[GH-ISSUE #1293] Missed Messages Possibility #918

New issue

Open

opened 2026-05-07 00:28:44 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-07 00:28:44 +02:00

Owner

Originally created by @preechaw on GitHub (Mar 14, 2025).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1293

The ntfy.sh Android app may lose the stream connection. When the app is reopened, the stream connection will be established, which is great. However, if the user doesn't pull down to refresh, they might miss some messages.
Let's say the last message id before the connection was lost was 1234. While there is no connection, there are two messages IDs 1235 and 1236. The user launches the app and the connection is reestablished. A new message ID 1237 is delivered. Now the "since" value has become 1237. Those two messages 1235 and 1236 will become inaccessible.
This can be reproduced by force stopping the app.

One possible solution is to let the app send poll=1&since=1234 at the time of connection reestablishment. Then 1235 and 1236 won't be missed.

Another possible solution is to set poll=0&since=1234 for the reconnection without another call with poll=1. This should be enough to prevent missed messages.

Originally created by @preechaw on GitHub (Mar 14, 2025). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1293 The ntfy.sh Android app may lose the stream connection. When the app is reopened, the stream connection will be established, which is great. However, if the user doesn't pull down to refresh, they might miss some messages. Let's say the last message id before the connection was lost was 1234. While there is no connection, there are two messages IDs 1235 and 1236. The user launches the app and the connection is reestablished. A new message ID 1237 is delivered. Now the "since" value has become 1237. Those two messages 1235 and 1236 will become inaccessible. This can be reproduced by force stopping the app. One possible solution is to let the app send poll=1&since=1234 at the time of connection reestablishment. Then 1235 and 1236 won't be missed. Another possible solution is to set poll=0&since=1234 for the reconnection without another call with poll=1. This should be enough to prevent missed messages.