MBombeck/HealthLog v1.4.47.2

v1.4.47.2 — APNs JWT signing repair

on GitHub

Same-day follow-up to v1.4.47.1. Coolify runtime logs surfaced

Notification sender threw for APNS:
  Failed to generate token: secretOrPrivateKey must be an asymmetric
  key when using ES256

on every push attempt. The admin UI reported the channel as Versand pausiert · sender_threw · 3 Fehler in Folge.

Root cause

The .p8 PEM stored in the Coolify env-var arrived at process.env.APNS_KEY without parseable newlines around the BEGIN / END markers — likely a docker-compose env_file round-trip artefact. openssl pkey could still parse it, but jsonwebtoken@9 (used by @parse/node-apn) is strict and refused to sign.

Changed

• src/lib/notifications/senders/apns.ts:loadApnsConfig — after the .replace(/\\n/g, "\n") 12-factor unescape, normalise the PEM body: strip whitespace between markers, force a 64-char line wrap of the base64 payload, and rebuild a canonical PEM. Idempotent on already-correct PEMs; recovers bare-base64 inputs without markers too. Then verify the result parses as an asymmetric EC key via crypto.createPrivateKey before handing to node-apn. On verification failure, return null with a one-time warning instead of sender_threw on every push.

Effect

• APNs channel returns to active on the next push attempt; the channel-state machine clears the cooldown on the first success.
• No env-var change required; the existing APNS_KEY value is normalised in-process.
• Already-correct multi-line PEMs are unaffected (idempotent re-wrap).

Risk

Low. Bad PEMs that previously caused sender_threw on every push now cleanly disable the APNs channel with a single warning at load time. Good PEMs are passed through unchanged.

Operator notes

Standard image roll. No prisma migrate deploy step required.