LibreOffice conversion Lambda wired via EventBridge; infinite-loop guard required for PDF passthrough
dropthejase built a separate x86_64 Lambda container running LibreOffice for DOCX-to-PDF conversion, triggered by EventBridge on docs-bucket uploads. The most operationally important piece: the Lambda must guard against re-triggering itself when it writes the converted PDF back to S3.
The conversion/ project gets its own TypeScript workspace with a production Dockerfile. The image uses Amazon Linux 2023 with dnf install -y libreoffice, npm ci --omit=dev, and node dist/index.js as the entry point. The architecture is x86_64 because LibreOffice is not available for ARM64 in the Lambda container base image.
The handler receives EventBridge S3 "Object Created" events - not S3Event Records arrays. The event shape difference matters: the key lives at event.detail.object.key, not event.Records[0].s3.object.key. 0ee216d fixes this after discovering the mismatch. Keys are URL-decoded with +-to-space replacement.
For .docx and .doc files the handler downloads from S3, runs docxToPdf() via the libreoffice-convert npm wrapper, uploads the PDF to converted-pdfs/ prefix, and updates document_versions.pdf_storage_path in Aurora via RDS Data API. For .pdf uploads, the file is already a PDF - the handler just records the source key as the pdf_storage_path.
The EventBridge infinite-loop fix (8afab46) is the critical operational piece. Three separate EventBridge rules (.docx, .doc, .pdf) are replaced by a single rule with a key prefix filter of documents/ and a suffix filter excluding the converted-pdfs/ prefix. Without this guard, the Lambda writing a converted PDF to the documents/ bucket would re-trigger itself.
libreoffice-convert is also removed from the API Lambda (1a11621) once the dedicated conversion Lambda takes ownership - the API Lambda had been carrying that dependency unnecessarily.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?