Skip to main content

Streaming y trabajos asincrónicos

Como en API, existen dos mecanismos diferentes:
  1. Transmisión de respuesta (/convert/stream): fragmentos de Markdown progresivo mientras el servidor convierte, leyendo el archivo directamente desde el disco con Bun.file.
  2. Trabajos por saturación (202): cuando todos los backends están ocupados, la solicitud se pone en cola y se responde a 202 con un job_id. Consulte GET /jobs/{id}.

Transmitiendo con convertStream

convertStream es un AsyncGenerator<string>; úselo con for await...of. Internamente, abre Bun.file(path) y lo transmite al cuerpo de POST /convert/stream, por lo que el archivo completo nunca se carga en la memoria antes de enviarlo.

streamSlimStrategy

  • "off": streaming puro por página, sin detección de ruido. TTFB mínimo.
  • "sampled" (predeterminado): muestra las primeras páginas y luego genera por página.
  • "full": materializa el documento completo antes de su emisión. Mejor limpieza, peor TTFB.
Consulte Parámetros.

Empleos por saturación (202)

De forma predeterminada, convertFile, convertBytes y convertFromUrl manejan 202 de forma transparente (autoPoll: true en el cliente):

Manual de encuestas

waitForJob equivale a llamar a getJob en un bucle respetando retry_after_seconds, pero encapsulado.
En condiciones de carga normales, no verá 202; solo sucede cuando todos los backends están saturados. autoPoll: true (el valor predeterminado) ya lo cubre sin código adicional en la mayoría de los casos.
Los resultados de los trabajos completados caducan en aproximadamente 1 hora. Si guarda un jobId y recibe 404 al consultarlo, reenvíe la conversión original.