[FIX] base_ux, mail_ux: stop the PDF render from calling the instance back over HTTP

[jcadhoc]

Rendering a PDF report is circular today: wkhtmltopdf resolves the report asset links (and the barcode images, when the report has any) against base_url, that is, against the very same Odoo instance. So a render occupies one HTTP worker and needs another free one to answer itself.

On an instance with workers = 3, three concurrent renders exhaust the three workers, nobody calls accept(), the backlog fills up and the port stops accepting connections. Everything stays blocked until limit_time_real (300s), but the liveness probe (tcpSocket 8069, 15s × 8) kills the container at 120s — so the pod never gets to recover by itself and the whole service goes down for 2 to 4 minutes.

The composer of a mail template amplifies it: attachment_ids is a compute with store=True, readonly=False, so the web client recomputes it on every round trip while the composer is opening, and each recompute renders the same PDF again.

Two independent changes, one per module.

base_ux: the report html no longer calls the instance back

_prepare_html post-processes the html handed to wkhtmltopdf:

• the report asset bundles are inlined as a <style> tag;
• the @font-face rules pointing back at the instance are dropped, keeping the font-family declarations. wkhtmltopdf resolves those families from the system fonts of the image that runs it;
• the /report/barcode/ images are embedded as data URIs, resolved in process through ir.actions.report.barcode() — the same code the controller uses.

Anything that cannot be resolved is left exactly as it was, so a report never fails because of this. It can be turned off with the system parameter base_ux.report_self_contained.

mail_ux: one render per composer, not 2 to 6

_compute_attachment_ids reuses the attachment already generated for the same report, the same record and the same write_date of that record, as long as it is still orphan (res_model = mail.compose.message, res_id = 0), was created by the same user and falls inside the reuse window. This also stops the orphan attachments from piling up in the database on every opening of the composer.

The reuse only kicks in for the case that causes the problem and that is unambiguous: comment mode over a single record with a single qweb report on the template. With more than one report there is no way to tell which created attachment belongs to which report, so core resolves it.

The window bounds how long a change that the report shows but that does not touch the record's own write_date (partner data, company data, a translation) could be seen stale. System parameter mail_ux.report_attachment_cache_ttl, 600 seconds by default, 0 disables the reuse.

Why this approach

• Raising workers does not close the door, it only moves the threshold: an instance with 8 effective workers (workers = 4, replicas = 2) hit the same deadlock. And it would mean paying for capacity to render the same PDF several times.
• Lowering limit_time_real below the probe's 120s would turn the outage into a recycled worker, but it leaves the deadlock in place and it is a platform side setting, not a fix.
• Adding a timeout and cancellation on the PDF service only changes how it fails ("the PDF failed" instead of "the instance is down for 5 minutes"). It does not make the PDF come out. Tracked separately on the platform side.

Measurements

Taken from the access logs of a production 19.0 instance, over a 9 hour window:

• 259 renders and 508 requests to /web/assets/*report_assets*, all of them coming from the loopback address — exactly 2 self-requests per render, which is what this PR removes.
• 0 requests to /web/static/fonts/ from that same loop, which is what makes dropping the local @font-face rules safe: nothing asks for those files today.
• Between 13% and 36% of the renders of any instance are the same document generated 2 to 6 times within seconds — the recompute storm this PR stops.

Test plan

• Open the mail composer on a purchase order (or any record with a mail template carrying a report), close it and open it again. The log must show one The PDF report has been generated per opening, and ir.attachment must not grow by 2 to 4 orphan rows each time.
• Edit the record and reopen the composer: the PDF must be generated again.
• Print any report and check the html handed to wkhtmltopdf has no <link> to /web/assets/ and no src="/report/barcode/". On the instance side, no request from the loopback address to /web/assets/*report_assets* during the render.
• Print a report that carries a barcode or a QR code (a delivery slip, an invoice) and check the image comes out.
• Set base_ux.report_self_contained to 0 and mail_ux.report_attachment_cache_ttl to 0: both behaviours must fall back to core.

Verified end to end against the same PDF service used in production: the report renders with the expected styling and page layout, with the text fonts resolved from the system.

The html of each rendered document grows by around 400 KB, the size of the inlined bundles.

Internal reference: https://www.adhoc.inc/odoo/helpdesk.ticket/126274

[roboadhoc]

[jcadhoc]

Closing in favour of ingadhoc/purchase#367.

This PR post-processed the report html to inline the asset bundles and overrode _compute_attachment_ids to memoize the rendered report — around 290 lines across two modules. Core already persists and reuses report PDFs through ir.actions.report.attachment / attachment_use, so the same behaviour is two data fields on the report and no Python at all.