Render a report to PDF or Excel
What It Does
A person with report-use access requests a PDF or supported Excel rendering. Status and downloads use the existing export-file operations.
The Flow
Open the report, check the requested format for its kind and commit the queued export with queued work. Dispatch the report export to the rendering queue and remove accepted queued-work entries. Start unfinished rendering and check that the requester still has report-use access and can open the report. Open the print page without a browser session and intercept allowed Platform reads as the requester, rejecting other requests. The print component loads source data and signals readiness or error on its document. Produce a bounded PDF or validate the page’s Excel output, store under the request key and settle success.
When Something Fails
Refuse source or format problems before admission. No file request is created by those checks. Leave unsuccessful publication for another dispatch pass. A render can remain queued or be redelivered after a publish/delete interruption. Settle source removal or lost access as access_lost. No browser starts for a refused source. A refused in-page request fails rendering. The browser result is not accepted as a valid report after a refused request. Page errors or readiness timeout fail the render. There is no accepted printable file until readiness succeeds. File-limit refusals settle without acceptance; infrastructure failures retry and become internal failure on the final receive. An upload followed by failed settlement can leave the object ahead of its running row.
Idempotency and Concurrency
The render request retains its export identity and storage key; terminal status prevents restarting settled work on redelivery. Rendering uses its own queue and headless-browser worker limits. It does not share the interactive query-file generator.