fix: API-key usage counter must not deny authentication (intermittent 403s)

[rutgerhofste]

The bug

_check_credentials bumps the usage counter with one UPDATE per authenticated call:

UPDATE res_users_apikeys
SET x_last_used = now() at time zone 'utc', x_use_count = x_use_count + 1
WHERE id = %s

When two requests using the same API key arrive concurrently, both update that row. At Odoo's REPEATABLE READ isolation the loser gets SerializationFailure (SQLSTATE 40001), which aborts the request transaction.

Odoo does know how to handle this — PG_CONCURRENCY_EXCEPTIONS_TO_RETRY in odoo/service/model.py lists SerializationFailure as retryable. But retrying() never sees it. The counter runs inside authentication, and _authenticate_explicit() in odoo/addons/base/models/ir_http.py does:

except Exception:
    _logger.info("Exception during request Authentication.", exc_info=True)
    raise AccessDenied()

So a retryable concurrency blip is converted to a hard 403 before the retry layer is reached, and a perfectly valid key is rejected. Bookkeeping takes down auth.

Seen in production

2026-07-15 08:15, key id 55, parallel crm.lead / res.partner calls from an MCP client:

ERROR odoo.sql_db: bad query: b"UPDATE res_users_apikeys SET x_last_used = ..."
ERROR: could not serialize access due to concurrent update
INFO odoo.addons.base.models.ir_http: Exception during request Authentication.
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update
... "POST /json/2/res.partner/check_access_rights HTTP/1.0" 403

Note this is intermittent and load-dependent — it only bites when the same key is used in parallel, which is exactly what a busy MCP client does.

The fix

Wrap the counter in a savepoint and swallow concurrent-update errors. The counter is best-effort; authentication is not.

Dropping an increment is free: x_use_count and x_last_used are readonly display fields, referenced only by the form view. Nothing reads them for cap enforcement or any other decision, so a lost count under contention has no downstream effect. A denied API call does.

Unexpected psycopg2.Errors are also swallowed (at warning, with traceback) rather than failing auth — same reasoning.

Verification

The load-bearing assumption is that ROLLBACK TO SAVEPOINT actually recovers a transaction after a 40001, rather than leaving it unusable. Confirmed against PostgreSQL with two concurrent sessions reproducing the exact production error:

SAVEPOINT
ERROR:  could not serialize access due to concurrent update
ROLLBACK
               verdict                | count
--------------------------------------+-------
 TRANSACTION STILL USABLE AFTER 40001 |     1
COMMIT

Also confirmed on the Odoo 19 runtime: all three psycopg2.errors classes resolve, cr.savepoint(flush=False) matches the signature in odoo/sql_db.py, and Savepoint.__exit__ rolls back but re-raises — hence the explicit try/except. ruff check and ruff format --check pass.

No unit test. tests/test_apikeys.py documents that _check_credentials needs a live odoo.http.request and is therefore covered by manual smoke plus staging rather than TransactionCase; this change doesn't alter that. Reproducing a genuine serialization failure additionally needs two concurrent transactions, which the single-cursor test harness can't express. Suggest a staging smoke: hammer one key with parallel calls and confirm no 403s.

Notes for review

• Branched off 19.0, independent of fix: two install/runtime crashes from the DCBO report (TOTP column leak + auditlog rule collision) #6 — but fix: two install/runtime crashes from the DCBO report (TOTP column leak + auditlog rule collision) #6 touches the same file and claims version 19.0.1.20.3, so this one takes 19.0.1.20.4. Whichever merges second may need a trivial manifest bump.
• CONCURRENT_UPDATE_ERRORS mirrors odoo.service.model.PG_CONCURRENCY_EXCEPTIONS_TO_RETRY rather than importing it, to keep a model from reaching into a service layer.
• Longer term the comment's own suggestion still stands: move the counter off the auth path entirely (deferred/batched write). This PR just stops it denying logins.

🤖 Generated with Claude Code

[rutgerhofste]

Rebased on 19.0 (now at d3f8d2c, after #9). Only the manifest version conflicted; the code applied clean. Version resolved to 19.0.1.20.4 on top of 19.0.1.20.3.

The bug is still live: production hit it again today, 2026-09-07 17:01 UTC, five SerializationFailures in 200ms on key id 33.

ERROR odoo.sql_db: bad query: b"UPDATE res_users_apikeys SET x_last_used = now() at time zone 'utc', x_use_count = x_use_count + 1 WHERE id = 33"
ERROR: could not serialize access due to concurrent update

Different key from the July report (33, was 55), same failure mode.

🤖 Generated with Claude Code