chatboxai/chatbox · error · Error

third_party_parser_not_supported_in_chat

Error message

third_party_parser_not_supported_in_chat

What it means

Thrown by parseFileWithMineruService when platform.parseFileWithMineru is falsy — i.e. the current runtime has no MinerU integration bound. MinerU is explicitly a Desktop-only feature, so on web or mobile the capability is absent and any non-text file routed to the mineru parser fails here immediately.

Source

Thrown at src/renderer/stores/sessionHelpers.ts:494

  }

  // Store content to unique key
  await storage.setBlob(uniqKey, content)

  return { content, storageKey: uniqKey, tokenCountMap: {}, parserType: 'chatbox-ai' }
}

/**
 * Parse file using MinerU service (Desktop only)
 */
async function parseFileWithMineruService(
  file: File,
  uniqKey: string,
  apiToken: string
): Promise<{ content: string; storageKey: string; tokenCountMap: Record<string, number>; parserType: string }> {
  // Check if platform supports MinerU parsing
  if (!platform.parseFileWithMineru) {
    throw new Error('third_party_parser_not_supported_in_chat')
  }

  // Call platform method to parse file
  const result = await platform.parseFileWithMineru(file, apiToken)

  // Handle cancellation - throw a special error that will be caught silently
  if (result.cancelled) {
    throw new Error('parsing_cancelled')
  }

  if (!result.success || !result.content || !hasParsedText(result.content)) {
    throw new Error(EMPTY_ATTACHMENT_CONTENT_ERROR)
  }

  const content = result.content

  // Store content to unique key
  await storage.setBlob(uniqKey, content)

View on GitHub (pinned to 81571269ad)

Solutions

  1. Switch the document parser to a build-supported option ('local' or 'chatbox-ai') in settings, or run on the Desktop build where parseFileWithMineru is bound.
  2. If you control the platform shim, register a parseFileWithMineru implementation (or a stub that throws a more specific error) so the guard passes.
  3. Gate the parser-config UI so 'mineru' is only selectable when platform.parseFileWithMineru is truthy, preventing users from picking an unsupported option.

Example fix

// before
if (!platform.parseFileWithMineru) {
  throw new Error('third_party_parser_not_supported_in_chat')
}
// after — fall back to a supported parser instead of hard-failing
if (!platform.parseFileWithMineru) {
  return parseFileWithLocalFallback(file, uniqKey, { forceChatboxAIFallback: true })
}
Defensive patterns

Strategy: type-guard

Validate before calling

// Before selecting the mineru parser, confirm the platform supports it.
function mineruIsAvailable(): boolean {
  return Boolean((platform as any).parseFileWithMineru)
}
if (parserConfig.type === 'mineru' && !mineruIsAvailable()) {
  // downgrade to a supported parser or warn the user
}

Type guard

function isMineruSupported(p: typeof platform): p is typeof platform & { parseFileWithMineru: (f: File, t: string) => Promise<unknown> } {
  return typeof (p as any).parseFileWithMineru === 'function'
}

Try / catch

try {
  return await parseFileWithMineruService(file, uniqKey, apiToken)
} catch (e) {
  if (e instanceof Error && e.message === 'third_party_parser_not_supported_in_chat') {
    return parseFileWithLocalFallback(file, uniqKey, { forceChatboxAIFallback: true })
  }
  throw e
}

Prevention

When it happens

Trigger: The effective document parser config resolved to type 'mineru' (or a caller invoked parseFileWithMineruService directly) while platform.parseFileWithMineru is undefined. The check runs before any network call, so no MinerU request is attempted.

Common situations: User synced a config (e.g. via settings import) that selects the MinerU parser onto a mobile/web build that doesn't ship the native bridge; running the renderer in a test harness where the platform shim lacks parseFileWithMineru; desktop build variant where the MinerU plugin failed to register.

Related errors


AI-assisted analysis of chatboxai/chatbox@81571269ad (2026-08-12). Data as JSON: /api/errors/3ce1a78234dd8b6f. Report an issue: GitHub.