← back to Dw Marketing Reels
TK-10929: report the real IG publish error instead of a hardcoded 2207076 diagnosis
5ca3af84f2b027b08088b1dde60b508473216b68 · 2026-09-16 14:07:33 -0700 · Steve Abrams
The failure alert (CNCP card + George email) hardcoded a diagnosis — "a 2207076
that survived the 3x retry -> verify IG content-publish permission / re-auth" —
and emitted it for EVERY publish failure regardless of the actual error.
For three weeks the real error was "fetch failed": a TRANSPORT failure, because
the Norma instagram-agent on :9810 was dead (never pm2-save'd, so the Sep-14
reboot left it permanently down). Node's undici only throws "fetch failed" when
the connection itself fails; a genuine Meta error arrives as a parsed code. But
every alert asserted a credential problem, so TK-10929 sat blocked on "NEEDS
STEVE: IG content-publish re-auth, not agent-fixable" while meta-token-canary
reported the tokens HEALTHY the entire time.
check-publish-status.mjs already printed the true reason on stderr; cron-run.sh
just discarded it. Now it captures that output, echoes it, and puts the observed
text in the alert plus a triage pointer at the right component.
An alert must never assert a cause it did not measure.
Verified with fault injection: on an injected "fetch failed" the alert carries
the real error + names norma-instagram, and the fabricated re-auth text is gone;
on a successful publish no alert fires and the OK line still reaches the log.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DdCubRnaMxvZPUoqCxMbZs
Files touched
Diff
commit 5ca3af84f2b027b08088b1dde60b508473216b68
Author: Steve Abrams <steve@designerwallcoverings.com>
Date: Wed Sep 16 14:07:33 2026 -0700
TK-10929: report the real IG publish error instead of a hardcoded 2207076 diagnosis
The failure alert (CNCP card + George email) hardcoded a diagnosis — "a 2207076
that survived the 3x retry -> verify IG content-publish permission / re-auth" —
and emitted it for EVERY publish failure regardless of the actual error.
For three weeks the real error was "fetch failed": a TRANSPORT failure, because
the Norma instagram-agent on :9810 was dead (never pm2-save'd, so the Sep-14
reboot left it permanently down). Node's undici only throws "fetch failed" when
the connection itself fails; a genuine Meta error arrives as a parsed code. But
every alert asserted a credential problem, so TK-10929 sat blocked on "NEEDS
STEVE: IG content-publish re-auth, not agent-fixable" while meta-token-canary
reported the tokens HEALTHY the entire time.
check-publish-status.mjs already printed the true reason on stderr; cron-run.sh
just discarded it. Now it captures that output, echoes it, and puts the observed
text in the alert plus a triage pointer at the right component.
An alert must never assert a cause it did not measure.
Verified with fault injection: on an injected "fetch failed" the alert carries
the real error + names norma-instagram, and the fabricated re-auth text is gone;
on a successful publish no alert fires and the OK line still reaches the log.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DdCubRnaMxvZPUoqCxMbZs
---
scripts/cron-run.sh | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/scripts/cron-run.sh b/scripts/cron-run.sh
index bef6187..56c3deb 100755
--- a/scripts/cron-run.sh
+++ b/scripts/cron-run.sh
@@ -41,9 +41,19 @@ SOCIAL_AUTOPOST="${SOCIAL_AUTOPOST:-1}" node scripts/publish-social.mjs
# email. We record the failure and still do the push, then exit non-zero at the very end so launchd
# sees the failure without losing the console push.
PUBLISH_FAILED=0
-if ! node scripts/check-publish-status.mjs; then
+# TK-10929 (2026-09-16): capture what the checker ACTUALLY observed and report THAT.
+# The previous MSG hardcoded a diagnosis ("a 2207076 ... verify IG content-publish
+# permission / re-auth") and emitted it for EVERY failure regardless of the real error.
+# For 3 weeks the true error was "fetch failed" — a TRANSPORT failure because the Norma
+# instagram-agent on :9810 was dead — yet every CNCP card + George email asserted a Meta
+# credential problem, so TK-10929 sat blocked on "NEEDS STEVE: IG re-auth" while the
+# tokens were healthy the whole time. An alert must never assert a cause it did not measure.
+CHECK_OUT="$(node scripts/check-publish-status.mjs 2>&1)"; CHECK_RC=$?
+echo "$CHECK_OUT"
+if [ "$CHECK_RC" -ne 0 ]; then
PUBLISH_FAILED=1
- MSG="TK-10395: nightly IG reel publish did NOT land (armed) on the $(date +%H:%M) run — a 2207076 that survived the 3x retry (now demonstrated PERSISTENT/flaky -> gated Option C: verify IG content-publish permission / re-auth). See reels.json publish.instagram + reels-cron.log."
+ REAL="$(printf '%s' "$CHECK_OUT" | tr '\n\r\t' ' ' | tr -d '"\\' | sed 's/ */ /g')"
+ MSG="TK-10395: nightly IG reel publish did NOT land (armed) on the $(date +%H:%M) run — OBSERVED: ${REAL} | TRIAGE: 'fetch failed' = TRANSPORT, i.e. the Norma instagram-agent :9810 is unreachable (check: pm2 describe norma-instagram; lsof -nP -iTCP:9810 -sTCP:LISTEN) — that is NOT a Meta credential problem. A genuine Meta failure (e.g. 2207076) arrives as a parsed error code, and token health is separately covered by meta-token-canary. See reels.json publish.instagram + reels-cron.log."
echo "IG PUBLISH CHECK FAILED — $MSG"
curl -sS --max-time 10 "${CNCP_URL:-http://localhost:3333}/api/parking-lot" \
-H 'Content-Type: application/json' \
← 59d297d auto-data-snapshot: 2026-09-16T11:14:29 (1 data files) — dat
·
back to Dw Marketing Reels
·
auto-data-snapshot: 2026-09-16T14:34:47 (1 data files) — dat e262e15 →