[16.0][FIX] fs_attachment: bound GC cursor with per-transaction timeouts

fs_attachment/__manifest__.py

@@ -5,7 +5,7 @@
 {
     "name": "Base Attachment Object Store",
     "summary": "Store attachments on external object store",
-    "version": "16.0.2.0.1",
+    "version": "16.0.2.0.2",
     "author": "Camptocamp, ACSONE SA/NV, Odoo Community Association (OCA)",
     "license": "AGPL-3",
     "development_status": "Beta",

fs_attachment/models/fs_file_gc.py

@@ -44,6 +44,18 @@ def _in_new_cursor(self) -> Cursor:
 
         with closing(self.env.registry.cursor()) as cr:
             try:
+                # Bound this cursor so it cannot hold a row lock on
+                # fs_file_gc indefinitely. Without these guards, a slow
+                # external storage backend (e.g. S3, Azure Blob) can leave
+                # the cursor "idle in transaction" while waiting on I/O,
+                # serialising every attachment write behind the unique
+                # constraint lock on fs_file_gc.store_fname. Every queued
+                # POST /mail/attachment/upload then times out at the
+                # session statement_timeout and returns a 500 HTML page,
+                # which the frontend tries to JSON.parse and fails with
+                # "Unexpected token '<', \"<!DOCTYPE\"...".
+                cr.execute("SET LOCAL statement_timeout = '30s'")
+                cr.execute("SET LOCAL idle_in_transaction_session_timeout = '60s'")
                 yield cr
             except Exception:
                 cr.rollback()

fs_attachment/readme/newsfragments/gc_cursor_timeout.bugfix

@@ -0,0 +1,15 @@
+Bound the GC cursor with per-transaction timeouts.
+
+The secondary cursor opened by ``FsFileGC._in_new_cursor`` had no upper
+bound, so a slow or unresponsive external storage backend (observed on
+Azure Blob, same class of issue applies to S3) could leave it
+``idle in transaction`` while waiting on network I/O. The cursor kept a
+row lock on ``fs_file_gc`` (via the ``store_fname`` unique constraint in
+``_mark_for_gc``), serialising every concurrent attachment write until
+the Odoo session ``statement_timeout`` killed it — by which time every
+``POST /mail/attachment/upload`` was returning a 500 HTML page, which
+the frontend tried to ``JSON.parse`` and failed with
+``Unexpected token '<', "<!DOCTYPE"...``. A ``SET LOCAL statement_timeout``
+and ``SET LOCAL idle_in_transaction_session_timeout`` on the new cursor
+cap the damage to 30-60 s and let the main transaction fail fast instead
+of stalling the whole instance.