{
  "version": "2",
  "id": "https://freelancenews.online/news/developer-s-test-matrix-shows-multi-device-push-migration-can-t-be-3623fdcc",
  "title": "Developer's Test Matrix Shows Multi-Device Push Migration Can't Be Verified From Server Code Alone",
  "summary": "A dev.to write-up reports that pairing old and new server versions with old and new logout methods produces four distinct outcomes, and that matching runtimeVersion labels do not prove compatible native builds.",
  "body": "A developer writing on dev.to has published an investigation arguing that a multi-device push-notification rollout cannot be judged complete by inspecting the new API alone. The post, attributed to the author's own testing of a project called SquadNote, compares the old and new tRPC routers against the old and new logout callers, and concludes that the server schema and the deletion scope used by every caller are separate conditions that must both be satisfied.\n\nThe underlying change, per the post, lets a server store multiple push tokens per user. The updated API upserts by token, so registering an iOS token and then an Android token preserves both registrations. Before the change, registering a previously unregistered token also removed the user's existing tokens, so registering iOS and then Android left only the later registration in the database.\n\nThe compatibility problem is that the updated API retains unregisterAllPushTokens. The author states that the mobile change must also reach clients so that an ordinary logout removes only that installation's tokens. Having an adequate server schema, the post argues, is not the same as having every caller use the new deletion scope.\n\nDisposable copies of a local libSQL database of the same type were connected to the actual before-and-after tRPC routers by the author, in order to test the combinations. A synthetic authenticated user first registered an iOS value and then an Android value; per the post, these were test strings, not real Expo Push Tokens. One of two deletions was then selected by the comparison: the device-specific deletion of the new caller, or the all-device deletion of the old caller.\n\nThe author is explicit that this exercised API calls, not an end-to-end run of the application UI and network. Their assertions were matched by all four cases. The old server cannot be made to retain both destinations by adopting only the new logout method, and both registrations are still removed by the new server if all-device deletion is called.\n\nOne case deserves attention because a final count alone would mislead. In the old-server-plus-device-deletion combination, the count reaches zero because registering Android had already removed the iOS row; device-specific deletion did not itself remove the iOS registration. The author recommends inspecting both the post-registration and post-logout states rather than only the final count.\n\nThe post also addresses whether updating the server restores registrations that were previously deleted. It does not. The test registered iOS again after logout and confirmed the row existed, but the author attributes that to another registration call with the required input, not to the server update reconstructing deleted rows.\n\nFrom this, the author proposes a verification sequence: the new code is distributed; it is downloaded and applied by the target device; registration is executed by the device; the required destinations are confirmed to exist on the server; and logout is then verified to preserve the other device. The post labels this a proposed sequence and states that the rollout stage of actual user devices was not collected by the investigation. The author therefore does not claim that every user updated or that all registrations were restored.\n\nA second thread takes Expo runtime versions as its subject. According to the post, the specification directs teams to ship the Web/API side first and afterward roll out compatible changes to iOS and Android, and it notes that the two platforms' targeted builds carry differing native dependency configurations. The author cites Expo's runtime-version documentation, which holds that an update must be compatible with the native code baked into a build, and contends that stamping the same identifier onto both platforms by hand does not erase those native differences.\n\nA rollout record, the author suggests, could link the applied update, the registration outcome, each platform's build and runtimeVersion, and the API commit. According to the post, delivery settings were not changed, and successful distribution was not inferred from local tests.\n\nOn test coverage, four additional cases passing alongside eight existing registration, deletion and sending tests are reported by the post, for twelve successful tests. Node.js v24.15.0 and Vitest 4.1.4 formed the environment, using in-memory libSQL and the actual router code, with external HTTP for notification sending mocked. Circle-hub at 0cda1e8 and the parent of change ad0a669 are the source versions cited, with tests run locally on September 11, 2026.\n\nThe author lists what these checks do not cover: permissions on physical devices, delivery after Expo accepts a message, OS notification presentation, and recovery from offline operation. The post also says no OTA update or notification to a physical device was sent.\n\nAt the inspected revision, the original specification's physical-device checklist is described as unchecked. That checklist asks for updates to be applied on both platforms, for receipt on both devices, and for receipt only on the remaining device once one logs out. The author's point is that a documented procedure is not evidence it was executed.\n\nFor developers and freelancers maintaining mobile apps with push notifications, the practical takeaway is editorial interpretation: a passing server test suite and a matching runtimeVersion string are weak signals of a finished migration. The post's matrix suggests auditing which logout path each shipped client actually calls, and recording per-platform build and update state alongside registration outcomes.\n\nThe tradeoffs are real. Retaining unregisterAllPushTokens for compatibility keeps older clients working but leaves a deletion path that wipes every device, so the safety of the rollout depends on client distribution rather than server behavior. The author's proposed verification sequence is more rigorous but requires device-level receipt checks that local tests cannot substitute for.\n\nWhat remains unknown is substantial. The evidence is a single author's account of local tests on synthetic token strings, with no physical-device verification, no data on actual user device rollout stages, and no confirmation that all registrations were restored. The post does not establish that any production deployment reached completion, and its conclusions should be read as the author's claims rather than independently verified findings.",
  "category": "dev",
  "language": "en",
  "datePublished": "2026-10-17T02:17:46.535Z",
  "dateModified": "2026-10-17T02:17:46.535Z",
  "eventDate": null,
  "sourcePublicationDate": "2026-10-17T01:48:27.000Z",
  "source": {
    "name": "dev.to",
    "url": "https://dev.to/hirodeath/a-multi-device-push-rollout-remains-incomplete-while-old-logout-behavior-survives-3881",
    "kind": "community"
  },
  "practicalImpact": "Editorial interpretation: teams shipping multi-device push should audit which logout path each released client calls and record per-platform build, runtimeVersion and registration outcomes, because server-side tests and matching version labels do not show that old all-device deletion has stopped being used.",
  "limitations": "This is a single author's dev.to account of local tests using synthetic token strings, not independently verified. No OTA update or physical-device notification was sent, the rollout stage of real user devices was not collected, and physical-device permissions, delivery after Expo accepts a message, OS presentation and offline recovery were untested. The physical-device checklist in the specification was unchecked at the inspected revision.",
  "keyPoints": [
    "The author reports that the updated API upserts by token and preserves a second device's registration, while the old API removed existing tokens when a new one was registered.",
    "The new API retains unregisterAllPushTokens, so the new server still deletes both registrations if an old caller invokes all-device deletion.",
    "In the old-server-plus-device-deletion case the final count reaches zero because registration, not the deletion call, removed the iOS row; the author advises checking post-registration and post-logout states.",
    "The author argues that matching runtimeVersion labels do not make different native dependency configurations identical, citing Expo's compatibility requirement.",
    "Twelve tests passed locally with mocked notification HTTP, but physical-device permissions, delivery, presentation and offline recovery were not covered."
  ],
  "review": {
    "status": "source-reviewed",
    "checkedAt": "2026-10-17T02:17:46.535Z",
    "method": "Automated comparison against retrieved source text; not independent fact-checking.",
    "correctionNote": null
  },
  "sources": [
    {
      "id": 1,
      "url": "https://dev.to/hirodeath/a-multi-device-push-rollout-remains-incomplete-while-old-logout-behavior-survives-3881",
      "publisher": "dev.to",
      "title": "A multi-device push rollout remains incomplete while old logout behavior survives",
      "publishedAt": 1792201707000,
      "fetchedAt": 1792203428895,
      "hash": "604d61cf5650c700ebc1ed0089a1bc265dafecadc8a76472d034324fb19c6675",
      "kind": "community"
    }
  ],
  "claims": [
    {
      "claim": "The updated API upserts by token and preserves another device's registration, but retains unregisterAllPushTokens for compatibility.",
      "source": 1,
      "id": "claim-1",
      "url": "https://freelancenews.online/news/developer-s-test-matrix-shows-multi-device-push-migration-can-t-be-3623fdcc#claim-1"
    },
    {
      "claim": "Before the change, registering a previously unregistered token removed the user's existing tokens, so registering iOS then Android left only the later registration.",
      "source": 1,
      "id": "claim-2",
      "url": "https://freelancenews.online/news/developer-s-test-matrix-shows-multi-device-push-migration-can-t-be-3623fdcc#claim-2"
    },
    {
      "claim": "The author tested the actual before-and-after tRPC routers against local libSQL using synthetic iOS and Android token strings, exercising API calls rather than the UI end to end.",
      "source": 1,
      "id": "claim-3",
      "url": "https://freelancenews.online/news/developer-s-test-matrix-shows-multi-device-push-migration-can-t-be-3623fdcc#claim-3"
    },
    {
      "claim": "In the old-server-plus-device-deletion case the count reaches zero because registering Android already removed iOS, so both post-registration and post-logout states should be inspected.",
      "source": 1,
      "id": "claim-4",
      "url": "https://freelancenews.online/news/developer-s-test-matrix-shows-multi-device-push-migration-can-t-be-3623fdcc#claim-4"
    },
    {
      "claim": "The author states that assigning the same runtimeVersion identifier manually does not make different native configurations identical, per Expo's compatibility requirement.",
      "source": 1,
      "id": "claim-5",
      "url": "https://freelancenews.online/news/developer-s-test-matrix-shows-multi-device-push-migration-can-t-be-3623fdcc#claim-5"
    },
    {
      "claim": "Twelve tests passed locally, but physical-device permissions, delivery after Expo accepts a message, OS presentation and offline recovery were not covered.",
      "source": 1,
      "id": "claim-6",
      "url": "https://freelancenews.online/news/developer-s-test-matrix-shows-multi-device-push-migration-can-t-be-3623fdcc#claim-6"
    }
  ],
  "formats": {
    "html": "https://freelancenews.online/news/developer-s-test-matrix-shows-multi-device-push-migration-can-t-be-3623fdcc",
    "markdown": "https://freelancenews.online/news/developer-s-test-matrix-shows-multi-device-push-migration-can-t-be-3623fdcc.md",
    "json": "https://freelancenews.online/news/developer-s-test-matrix-shows-multi-device-push-migration-can-t-be-3623fdcc.json"
  }
}