Make a wrong FN_APNS_ENV diagnose itself (ios#7) #134

Merged
paulhitt merged 1 commits from fix/apns-env-mismatch-says-so into main 2026-09-07 09:55:05 +00:00
paulhitt commented 2026-09-07 01:55:11 +00:00 (Migrated from gitlab.com)

ios#7 asks for verification on two physical devices, which is the only
way to exercise push, VoIP push and the microphone. That part cannot be
done from here. What can be done is removing the reason it is dangerous.

The relay defaults to the APNs SANDBOX host. A TestFlight or App Store
build mints tokens only the production host understands. Ship without
setting FN_APNS_ENV=production and every push is refused, no iPhone
ever rings, and the log says:

APNs refused a push: 400 {"reason":"BadDeviceToken"}

which reads as a bad token. It is not a bad token; it is the one setting
nobody remembered. A total, silent failure of the feature people notice
first, presented as somebody else's problem.

Now it says:

APNs refused a push: 400 BadDeviceToken. This relay is sending to the
sandbox host, so this is almost certainly a token from a production
build — set FN_APNS_ENV=production and restart. Until then no push
from this relay will arrive.

"Almost certainly", never "is". APNs returns the same reason whichever
way round the mismatch is, and a genuinely malformed token produces it
too — a diagnosis stated as fact would send somebody to change a
configuration that was right. Every other refusal is passed through
untouched, so an unrelated failure does not acquire an environment
theory.

Two more things it was hiding:

  • The VoIP branch threw the reason away entirely and logged only
    "failed: 400" — the path where this matters most, because a call
    that never rings is what gets noticed first.
  • Startup logged the environment at notice, one line among a hundred.
    Sandbox is the DEFAULT and production is the deliberate state, so
    sandbox now warns, saying plainly that no TestFlight build can
    receive anything.

670 tests on macOS, and a clean Linux build in swift:6.1-noble.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

ios#7 asks for verification on two physical devices, which is the only way to exercise push, VoIP push and the microphone. That part cannot be done from here. What can be done is removing the reason it is dangerous. The relay defaults to the APNs SANDBOX host. A TestFlight or App Store build mints tokens only the production host understands. Ship without setting `FN_APNS_ENV=production` and every push is refused, no iPhone ever rings, and the log says: APNs refused a push: 400 {"reason":"BadDeviceToken"} which reads as a bad token. It is not a bad token; it is the one setting nobody remembered. A total, silent failure of the feature people notice first, presented as somebody else's problem. Now it says: APNs refused a push: 400 BadDeviceToken. This relay is sending to the sandbox host, so this is almost certainly a token from a production build — set FN_APNS_ENV=production and restart. Until then no push from this relay will arrive. "Almost certainly", never "is". APNs returns the same reason whichever way round the mismatch is, and a genuinely malformed token produces it too — a diagnosis stated as fact would send somebody to change a configuration that was right. Every other refusal is passed through untouched, so an unrelated failure does not acquire an environment theory. Two more things it was hiding: - The VoIP branch threw the reason away entirely and logged only "failed: 400" — the path where this matters most, because a call that never rings is what gets noticed first. - Startup logged the environment at `notice`, one line among a hundred. Sandbox is the DEFAULT and production is the deliberate state, so sandbox now warns, saying plainly that no TestFlight build can receive anything. 670 tests on macOS, and a clean Linux build in `swift:6.1-noble`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
paulhitt commented 2026-09-07 01:55:11 +00:00 (Migrated from gitlab.com)

assigned to @paulhitt

assigned to @paulhitt
paulhitt commented 2026-09-07 09:55:05 +00:00 (Migrated from gitlab.com)

mentioned in commit d3723202f1

mentioned in commit d3723202f1595753e3e01739aada7920b28656a2
paulhitt (Migrated from gitlab.com) merged commit d3723202f1 into main 2026-09-07 09:55:05 +00:00
paulhitt commented 2026-09-09 18:58:51 +00:00 (Migrated from gitlab.com)

changed the description

changed the description
Sign in to join this conversation.