Meta OAuthException #1 kills carousel child-container creation (systematic since 2026-09-08?) #258

Summary

Two scheduled carousels failed with identical signatures at child-container creation:

Error (both): Failed to create carousel item: Threads API error: An unknown error occurred [OAuthException #1] (HTTP 400 Bad Request)

Ruled out

• Token: valid both days; TEXT/IMAGE posts on the same account kept publishing throughout.
• Media: all 10 slide URLs HTTP 200, JPEG 1080px, 89–153KB (within all limits).
• Titen regression: carousel code path is byte-identical between v0.9.1 and v0.9.2; the Sep 8 failure ran on the pre-restart v0.9.1 process.
• Orphan posts: both rows have result_post_id = null and failed at step 1/4 (before any container existed) — nothing is live from these attempts.
• Precedent: Aug 27 (guyonlelucon, single IMAGE, feat: fix Docker files + add release workflow #1) failed once and the next-day repost published fine.

Suspected root cause

Meta-side transient/systematic block on the child-container endpoint (POST /{user-id}/threads with media_type=IMAGE&is_carousel_item=true) — NOT a Titen bug. Can't probe directly because production tokens are encrypted at rest and not exposed via the API (by design).

What shipped in #257

• Bounded scheduler retry (1x, +10 min) for transient errors (feat: fix Docker files + add release workflow #1, create_post tidak handle VIDEO media type #24, 429/5xx).
• Carousel failure errors now include child index, total, offending URL, and orphaned child IDs.
• attempt_count persisted for audit.

Follow-ups

• If the 19:00 WIB Sep 10 canary carousel also fails with feat: fix Docker files + add release workflow #1, stop scheduling carousels until Meta recovers and consider a Threads UI fallback lane.
• Consider reporting to Meta with both trace signatures if the block persists > 7 days.