Repository navigation
Messages doesn't work - missing texts #371
Description
Describe the bug
Received SMS message on phone are not shown on PlainApp at all,, anywhere.
To Reproduce
Steps to reproduce the behavior:
When an SMS is received on the phone, go to Messages on Plain App - it isn't there, the count of messages doesn't increase, it never shows.
Expected behavior
Messages includes any message received by the phone's Message App
Desktop (please complete the following information):
Windows 10 (doesn't matter because issue is the PlainApp, not the browser/PC/OS)
Smartphone (please complete the following information):
Pixel 10, Android 17, 3. PlainApp 3.3.25
Additional context
Third day with this app - there are so many bugs - more reports coming unless I totally give up on this app, because this bug is a deal breaker as Messages was my primary reason for trying this app. None of the new SMS sent to me show up, I was able to compose a new SMS and send it successfully with the app and it shows both on the app and on the phone.
I would note - the SETTINGS screens and much of the UI on App itself as well as the browser are unreliable:
Security Settings -> Notifications I have toggled it ON, it goes to OFF by itself sometimes (not sure why - have never had this problem with any other app) The permission right above notifications - Manage Apps - I toggle OFF, but when toggled OFF it still says 'system permission granted.' And, if I freeze the app, when thawed, for sure the Notifcation permission goes back to OFF and the Manage Apps permission turns ON. Have similar issues in other places where it seems like changing a setting actually changes a different setting than the label indicates.
Activity
ismartcoding commentedon Sep 17, 2026
Thanks for the report. A few notes:
Notification access turning off: This is Android's behavior, not PlainApp's. Freezing (or force-stopping) an app makes Android revoke its Notification access — it must be re-granted after unfreezing. Same happens with Pushbullet, KDE Connect, Tasker, etc. Which apps did you compare with?
"System permission granted": The switch only controls whether your desktop client may use this feature; the subtitle shows the Android OS-level grant. Turning the switch off doesn't revoke the OS grant — Android doesn't let apps do that. We'll make the wording clearer in a future update.
Missing SMS: We're trying to reproduce it. Does a new SMS show up after you refresh the web page?
th317erd commentedon Sep 17, 2026
@modernman1 Welcome to open source software! The nature of it is that it is open and free. Please don't come here making demands, threats, and telling us how terrible our software is. Only two developers are working on this app in our spare time. Feel free to move to an alternative software (if you can find one... and one that works better).
In the meantime, your request is heard. We have already been focused on syncing issues these past few weeks. We will persist in fixing things, and your request matters to us. This is a personal open-source project, that people are lovingly working on in their spare time. Please be patient.
Also, please keep the requests coming. I appreciate the bug report, but I do not appreciate the attitude. Donate a big fat sum to us, AND THEN you can have an attitude. If you aren't willing to do that, then please be patient, kind, and understanding. I know that bugs like these are frustrating (I use this product every day, and I can tell you, even as one of the developers here, that this issue IS frustrating). We will get to fixing it soon, and we will post here to let you know it is fixed when the fix is complete.
Thank you for understanding and for cooperating!
th317erd commentedon Sep 19, 2026
@ismartcoding I am investigating this against current upstream, alongside #369. Could you please assign this issue to @th317erd? Self-assignment is denied by repository permissions. I have reproduced a separate chronological-ordering defect in the shared frontend with a failing regression test; incoming-message visibility and pending-send recovery are still under investigation. I will post the evidence and linked fixes here.
th317erd commentedon Sep 19, 2026
@modernman1 I am working on this and have reproduced frontend ordering and refresh-recovery defects. I have not yet reproduced the permanent absence of incoming messages from the backend: on a Pixel 9 Pro running Android 17 and PlainApp 3.3.25, a fresh API read currently contains all 16 recent SMS provider rows, including eight incoming messages. Could you confirm whether a missing message is identified as SMS/MMS or RCS in your phone messaging app, and whether it remains missing after a browser reload (as requested above)? Also, does it appear in PlainApp on the phone itself? Please do not post message contents or phone numbers; the transport type and those results should help separate provider access from client refresh problems.
th317erd commentedon Sep 19, 2026
Scoped frontend PR: plainhub/plain-desktop#27
Related background-service PR: #373
This report does not claim the permanently missing incoming-message case is resolved; the clarification request above remains open.
SMS synchronization investigation — #371
Status: investigation and implementation in progress (2026-09-19).
Reproduced: mixed pending/provider ordering
The thread sorted provider rows and then appended pending SMS and MMS. Thus a
pending message timestamped 13:58 appeared below a provider message at 13:59,
matching the ordering pattern in the owner's screenshot. This is a frontend
projection defect, independent of Android process suspension.
A failing-first hook regression reproduced the reversed order in real headless
Chromium. Sorting the combined list corrects it without changing provider data.
The focused message-thread, message-helpers and sms-state-sync suites pass: 26 tests.
This proves the code-level ordering correction, not yet its installed-device behavior.
Other symptoms under investigation
Missing incoming messages, disappearing sends, terminal send status and Android
background service reliability require separate evidence. Current upstream already
preserves successful pending SMS as Sent when provider readback does not find them.
The test phone already has READ_SMS and a battery-optimization exemption; simply
asking for those permissions again would not explain the observed behavior.
No claim is made yet that all reported symptoms have the same cause or are fixed.
Reproduced: refresh recovery gaps
Failing-first tests demonstrated that repeated provider events could postpone the
debounced refresh indefinitely, returning to a visible tab did not trigger readback,
and slow reads could overlap. The shared thread/sidebar scheduler now caps event
batching at two seconds, coalesces triggers during a read into one follow-up, and
refreshes on visibility/focus/network restoration. A visible, online Messages view
also reads back once per minute if events are missed entirely. It removes timers and
listeners on deactivation. This is a recovery bound while the browser is scheduled
and the backend is reachable, not a guarantee during OS suspension.
Background refresh retains the loaded thread/conversation window size and avoids
forcing a reader of older messages to the bottom. Readers already at the bottom
continue following incoming messages. Safety reads add network/provider work while
Messages remains visible, and can keep the server's inactivity window active.
Live evidence and limitations
A read-only comparison on the authorized Pixel 9 Pro (Android 17, PlainApp 3.3.25)
found all 16 SMS provider rows newer than 2026-09-18T00:00:00Z in a fresh authenticated
API response: eight incoming and eight outgoing, with matching IDs. No private
message contents or identifiers are included here. This sample does not reproduce
permanently missing incoming rows. The issue author has been asked for transport
type (SMS/MMS versus RCS), phone-side visibility and browser-reload behavior.
Testing the new production frontend against the installed 3.3.25 backend exposed
upstream schema incompatibilities: App.features, Query.deviceStatus and
Query.audioQueueItems are absent in that release. The SMS query itself returned
99 rows for a sampled recent thread, but the new frontend could not render a usable
thread in that mixed-version setup. The phone's installed release and its settings
have not been replaced. A matching debug APK was installed alongside the release;
physical-phone setup awaits unlocking the device.
A matching 3.4.0 debug backend was subsequently built and installed in a disposable
Android 12 emulator. The production frontend, served through a loopback-only test
proxy, logged in using the real pairing flow. Emulator-only SMS injection verified:
message is recovered by the safety read after 60.2 seconds, without reloading.
With the emulator radio disabled, the failed send restores the draft instead of
leaving a Sending bubble. Neither test is a real carrier-delivery test.
The emulator tests do not prove carrier sending, RCS visibility, MMS attachments,
or every OEM's background restrictions. A test-harness cleanup call was unsupported
after the three assertions passed; it did not invalidate those observations.
Verification at the first local milestone
corepack yarn test: 1,142 passed, 51 skipped across 127 files. Live integrationtests are among the skipped tests; these are not device verification.
corepack yarn typecheck: passed.corepack yarn build: passed.git diff --check: passed.:shared:testAndroidHostTest --tests '*SmsSyncContractTest': 25 passed.:app:assembleDebug: passed in 3m21s with a 10-minute command bound.Assignment was requested from the owner after GitHub denied self-assignment.
This is a scoped fix, not a final resolution claim for every #371 symptom. The
author's report of permanently absent incoming messages remains unconfirmed.
The related #369 Android change reproduces and repairs task-removal shutdown and
wake-lock reacquisition defects; its report is in the Android repository.
th317erd commentedon Sep 19, 2026
Physical-device follow-up: on the owner’s Pixel 9 Pro / Android 17, one authorized outgoing SMS became a sent provider row and remained visible. Both replies then appeared in the already-open test browser without reload, in chronological order, after the debug app’s activity tasks had been removed from Recents. No stuck Sending indicator. The release app was left unchanged. This was USB-powered/forwarded testing, not a Doze or sustained Wi-Fi guarantee. Two older test rows remain absent from both release and debug APIs; that separate discrepancy is not claimed fixed. Updated evidence is committed in frontend PR plainhub/plain-desktop#27 and the related background PR #373.
fix: recover SMS views after missed update events (#27)