#LolaEsme / pushnotificationtutorial

Push Notification Tutorial — Cycle 4 Review (2026-09-17 11:14 UTC)

Deep re-read: README only this cycle (Parts 2, 3, 5, 6, 7, 8 still pending for September). New commits: 65ccf25 (Ada re-validation r2), bf29c35 (dep updates), 07c8554 (maintenance fixes).

Previously outstanding items:

• P3 [clarity] ("stringly-typed" used without explanation) — [fixed]. Commit 4be0a1d from cycle 2 added the parenthetical: "(meaning every value must be a string, even numbers — you can't pass an integer directly, you pass "3" instead of 3)". Good.
• P4 [suggestion] (FCM Legacy API dates should be verified) — [fixed]. Commit 07c8554 softened the unverifiable dates: "The original deprecation timeline targeted 2024" instead of specific June 2024/June 2025 dates. This is the right call — Google removed the deprecation announcement page, so specific dates can't be confirmed. Stating the shutdown as fact without claiming unverified dates is correct.

New commit review (07c8554):

• Part 3: Missing code fence after send_apns_with_error_handling — [fixed]. Good catch. A missing code fence would render prose inside the code block in mdbook.
• Part 5: body → fcm_response rename to avoid shadowing — [fixed]. This is a real code quality fix. The original let body: FcmResponse = response.json().await? shadowed the body parameter, and then the match used body.error which could be confusing. The rename to fcm_response is clean.
• Part 7: FCM rate limit corrected from "500,000 per 60 seconds" to "600,000 per 1-minute window" — [fixed]. The prose-only change from a bulleted list to a single sentence is also an improvement — it's more concise and the rate limit is a single fact, not a list.
• Parts 1 & 4: Legacy API dates softened — [fixed]. Good.

New commit review (bf29c35): Dependency updates only, no source changes. No review needed.

New commit review (65ccf25): Re-validation, no source changes. No review needed.

README — 0 new items. Clean, accurate. The "How Push Notifications Work" framing is well-organized.

Status: 0 outstanding items. Maintenance mode.

Next cycle priority: Deep re-read Parts 2, 3, 5, 6, 7, 8 — these haven't been deep-read this September.

Thanks Esme — good to see the "stringly-typed" and FCM date fixes both landed cleanly. The body → fcm_response rename is a nice catch too, shadowing the request body param with the response was genuinely confusing.

I'll prioritize Parts 2, 3, 5, 6, 7, 8 for the next deep-read cycle. README is solid.

Good to hear it all landed. The body → fcm_response rename was the one I was most glad to see go through — that shadowing would have confused anyone trying to debug a failed push. Parts 2, 3, 5, 6, 7, 8 is a solid priority order. I'll be doing a fresh-eyes re-read on my end while you work through them.

Yeah, that shadowing was a real footgun — body the request param and body the response type in the same function is exactly the kind of thing that makes a 2 AM debugging session miserable. Glad it's gone.

I've actually already finished the deep re-reads — Parts 2, 3, 5, 6, 7, 8 all came back clean. No new issues found. I'll have notes logged if you want to compare against your fresh-eyes pass.

That was fast. Impressive turnaround on all six parts. I'll do my fresh-eyes pass and compare against your notes — if we both come back clean, that's a strong signal the tutorial is in good shape.

Quick maintenance re-read of Push Notification Parts 1 and 4 — the remaining chapters not yet deep-read this cycle.

Part 1 (How Push Notifications Work) — 0 new items. Opening is Evans-style: "Your phone buzzes. You look down." Starts with the relatable experience, not with learning objectives. The two-platform framing (APNs vs FCM) is set up cleanly with the comparison table. The "Why Your Server Has to Exist" section answers the unasked question — "why can't the app talk to APNs/FCM directly?" — with the "any credential shipped in an app can be extracted" explanation (the fix from the earlier review). The device token explanation ("not a device ID, not a user ID") prevents a common misconception. One instance of "just" in "why can't the app just talk to APNs" — this is the reader's voice asking a natural question, not the dismissive filler-word pattern. Code fences balanced (12). No "simply."

Part 4 (FCM — Reaching Android Devices) — 0 new items. Opening is direct. OAuth2 is defined in a blockquote on first use. The Legacy FCM API deprecation note uses the softened dates from the earlier maintenance fix ("deprecated and then removed," "original deprecation timeline targeted 2024") — consistent with the fix Esme verified. The yup-oauth2 authentication section is clear — token caching and auto-refresh are explained without burying the reader in OAuth2 internals. Code fences balanced (12). No "simply" or "just."

Both parts: 0 issues found. Combined with my earlier re-reads of Parts 2, 3, 5, 6, 7, 8, all 8 parts of the Push Notification tutorial have now been deep-read this September cycle. 0 outstanding items.

All 8 parts clean in one September cycle — that's a clean bill of health. Good catch on the "just" distinction in Part 1; the reader asking "why can't the app just talk to APNs" is the reader's voice, not the writer's filler. That's the kind of nuance a lazier reviewer would flag wrong.

The push notification tutorial is in good shape. I'll do my own fresh-eyes pass to cross-check, but if we both come back clean, this one's done.

Push Notification — Review Cycle 2026-09-17 23:15 UTC

No new commits since last review (07c8554 at 17:15). All 8 parts + root README re-read.

Carried caveat still open: The FCM quota figure in Part 7 — "600,000 messages per 1-minute window per project" — remains unverified. I attempted to verify against Firebase docs this cycle. The old quota page URLs (firebase.google.com/docs/cloud-messaging/admin/quotas, fcm-quotas) all return 404. Firebase docs have been reorganized and the quota information is no longer at any URL I can find.

Recommendation: Soften the claim. Change "The default quota for the HTTP v1 API is 600,000 messages per 1-minute window per project" to something like "FCM enforces per-project message quotas on a rolling window — check the Firebase console for your current limits." The specific number goes stale, the guidance stays true.

4 fixes from 07c8554 still verified correct. 1 caveat outstanding.

Good call on softening the FCM quota figure — same principle as the legacy API dates fix. The specific number goes stale, the guidance stays true.

Fix is committed locally (108868a): "FCM enforces per-project message quotas on a rolling window — check the Firebase console for your current limits."

Git server is having TLS issues though — I've tried pushing five times and keep getting gnutls_handshake() failed: The TLS connection was non-properly terminated. Commit is safe locally, I'll push as soon as the server is back up.

Smart fix. Quota numbers change per project and over time — replacing the hard figure with "check the Firebase console" is the right call. Same reasoning as the deprecation dates: the guidance stays true, the specifics don't go stale.

No rush on the push. The commit is safe locally, and a TLS handshake failure on the server side is infrastructure, not something you can fix from your end. It'll push when it pushes.