From 31ba6678d7e68688d9e99b5fa75fbda398d6f1a4 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 26 Aug 2026 00:08:18 +0000 Subject: [PATCH] Add FQDN-change-specific causes to the push-notification troubleshooting doc DNS propagation lag, TLS cert readiness, and a stale SiteURL all follow directly from a migration that also changes domains, on top of the DB-import device-registration cause already documented. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01AddPmva5bfrUW3MoPriq21 --- services/mattermost.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/services/mattermost.md b/services/mattermost.md index 93fcccc..6c7cd62 100644 --- a/services/mattermost.md +++ b/services/mattermost.md @@ -79,3 +79,30 @@ carrier blocking something, a half-finished Caddy/DNS cutover for the new VPS), that user can receive the push notification itself but never see real content, or see it inconsistently. Temporarily switching to "Send full message contents" removes this variable while narrowing down the cause. + +### 5. A changed FQDN specifically — DNS propagation and cert readiness + +If the migration also moved the server to a new domain (not just a new box +under the same domain), that alone can produce exactly this +some-users-fine/some-users-not pattern for a few days after cutover, on top +of section 2 and 4 above: + +- **DNS propagation lags per device.** Different users' resolvers (ISP DNS, + carrier DNS on cellular, cached records with old TTLs) pick up the new + FQDN's IP at different times. A user on a fast public resolver sees it + immediately; someone on carrier DNS with a stale cache might not resolve + it correctly for hours. Combined with section 4 (anything but "full + message contents" requires a content-fetch call back to `SiteURL`), a + device with a stale answer for the new FQDN fails that step while others + succeed. +- **TLS certificate not fully issued/propagated yet** for the new FQDN + (Caddy/Let's Encrypt) causes the same content-fetch failure via cert + validation instead of DNS. +- **Confirm `MM_SERVICESETTINGS_SITEURL` in `.env` is actually the new FQDN** + — a value left over from before the domain change points every client's + content-fetch at the wrong place, consistently, not just intermittently. +- Users who never explicitly added the new server URL in the mobile app (a + kept redirect from the old domain let them keep working without + noticing) are still running on their old, stale device registration — + this is section 2's mechanism, just caused directly by the FQDN change + rather than by the DB import alone.