gitroomhq/postiz-app · error · BadBody

Threads took too long to process the media, please try again

Error message

Threads took too long to process the media, please try again

What it means

checkLoaded polls the Threads container until it finishes processing. After exhausting the retry loop with timer(2200) delays, if the container still is not ready it throws 'Threads took too long to process the media, please try again'.

Source

Thrown at libraries/nestjs-libraries/src/integrations/social/threads.provider.ts:220

    accessToken: string
  ): Promise<boolean> {
    // Bounded (the old version recursed forever and could hang the activity
    // into a timeout): ~5.5 minutes at 2.2s intervals.
    for (let i = 0; i < 150; i++) {
      const status = await this.checkContainerStatus(
        mediaContainerId,
        accessToken
      );

      if (status === 'FINISHED' || status === 'PUBLISHED') {
        await timer(2000);
        return true;
      }

      await timer(2200);
    }

    throw new BadBody(
      this.identifier,
      '{}',
      '{}',
      'Threads took too long to process the media, please try again'
    );
  }

  private async fetchUserInfo(accessToken: string) {
    const { id, username, threads_profile_picture_url } = await (
      await this.fetch(
        `https://graph.threads.net/v1.0/me?fields=id,username,threads_profile_picture_url&access_token=${accessToken}`
      )
    ).json();

    return {
      id,
      name: username,
      picture: threads_profile_picture_url || '',

View on GitHub (pinned to 0f1647f749)

Solutions

Retry the post - processing usually completes on a fresh container
Reduce video size/bitrate before uploading
If it recurs constantly, check Meta platform status and the container's actual status via the Graph API

Defensive patterns

Strategy: retry

Try / catch

try { await publishThread(...); } catch (e) { if (/took too long/.test(e.message)) scheduleRetry(post, backoffMinutes(5)); else throw e; }

Prevention

Compress videos before scheduling to Threads
Schedule retries for slow-processing errors instead of resubmitting instantly
Watch Meta platform status during mass failures

When it happens

Trigger: Threads' media processing (usually video transcoding) exceeds the fixed poll budget in the loop; slow Meta-side processing of large videos is the typical cause.

Common situations: Large or high-bitrate videos near Threads' limits during peak load, or a container stuck in IN_PROGRESS that never transitions.

Related errors

AI-assisted analysis of gitroomhq/postiz-app@0f1647f749 (2026-08-27). Data as JSON: /api/errors/947b797b7a6e4bdf. Report an issue: GitHub.