DIYgod/RSSHub · error · Error

Unhandled attachment type: ${attachment.contentType} for pos

Error message

Unhandled attachment type: ${attachment.contentType} for post ${attachment.postId}

What it means

The Fansly attachment renderer switches on a numeric `contentType` (e.g. 7100 tip goal, 42001 poll, 32001 unknown -> empty string, plus media cases handled above). Any unrecognised contentType hits `default` and throws a generic Error that includes both the contentType and the postId. This is a parser-completeness gap that fails the whole post.

Source

Thrown at lib/routes/fansly/utils.tsx:116

                case 8: {
                    // aggregated post (repost)
                    let attachments = '<br><br>';
                    const repost = aggregationData.aggregatedPosts.find((post) => post.id === attachment.contentId) || aggregationData.posts.find((post) => post.id === attachment.contentId);
                    attachments += parseDescription(repost, aggregationData);

                    return attachments;
                }

                case 7100:
                    return renderTipGoal(attachment.contentId, aggregationData.tipGoals);
                case 32001:
                    // unknown
                    return '';
                case 42001:
                    return renderPoll(attachment.contentId, aggregationData.polls);

                default:
                    throw new Error(`Unhandled attachment type: ${attachment.contentType} for post ${attachment.postId}`);
            }
        })
        .join('');

const parseMedia = (contentId, accountMedia) => {
    const media = accountMedia.find((media) => media.id === contentId);
    if (!media) {
        return '';
    }
    return renderMedia(media.preview ?? media.media);
};

const renderMedia = (media) => {
    switch (media.mimetype) {
        case 'image/gif':
        case 'image/jpeg':
        case 'image/png':
        case 'video/mp4':

View on GitHub (pinned to bed535e087)

Solutions

1. Read the contentType from the error message and add a case (or map it to an existing renderer).
2. As a stopgap, return an empty string in the `default` arm so the post renders without the unknown attachment.
3. Log the contentType/postId so newly added codes surface quickly.

Example fix

// before
//   default:
//       throw new Error(`Unhandled attachment type: ${attachment.contentType} for post ${attachment.postId}`);
// after
//   default:
//       return '';

const KNOWN_ATTACHMENT_TYPES = new Set([/* media codes */, 7100, 32001, 42001]);
function isKnownAttachment(a: { contentType: number }): boolean {
  return KNOWN_ATTACHMENT_TYPES.has(a.contentType);
}

function isKnownAttachment(a: { contentType: number }): boolean {
  return KNOWN_ATTACHMENT_TYPES.has(a.contentType);
}

try {
  return renderAttachment(attachment);
} catch {
  return '';
}

When it happens

Trigger: Fansly introduces a new attachment contentType code not listed in the switch.

Common situations: An upstream API addition ships a new attachment kind; posts containing it fail to render.

Related errors

• Unknown node type: ${node.type}
• Unknown type: ${v.type}
• Unhandle type: ${c.type}
• Unhandled media type: ${media.mimetype}
• Unknown action key: ${item.key}

AI-assisted analysis of DIYgod/RSSHub@bed535e087 (2026-08-12). Data as JSON: /api/errors/27820aae2faa69e0. Report an issue: GitHub.