safe-global / safe-decoder-service / 34602206498

91%

Build Type

push

github

Committed by web-flow

Commit Message

feat: Load contract ABIs outside the blocking startup path (#342)

* feat: Load contract ABIs outside the blocking startup path

The web app loaded every ABI inside the FastAPI lifespan, before yield. Any
exception or slowness there leaves server.started as False, the uvicorn worker
exits with WORKER_BOOT_ERROR and the gunicorn master halts, so the container
dies and does not recover while the condition lasts. Two of the three startup
steps talk to the database, so every pod restart needed a healthy and fast
database.

The ABI load now runs in a background task that retries, and readiness is
published when it finishes. /health stays as liveness, with /health/live as an
alias matching the naming the other Safe services use, and /health/ready is the
new readiness endpoint. The decode endpoint answers 503 with Retry-After while
the ABIs are not loaded, instead of blocking on the in-flight load. A failed
ABI reload no longer fails a decode request either, so decoding keeps working
from the selectors already in memory while the database is unreachable.

Startup is also cheaper: the selector map is built with one thread hop per
batch instead of one per ABI. Measured on 100k rows in abi, 14.4s before and
1.9s after. Raising the streaming row buffer with yield_per was tried and
dropped, it made no measurable difference and only raised peak memory.

load_new_abis ran on every decode request, opening a transaction or waiting up
to 10ms on a lock. It is now throttled to DECODER_ABI_RELOAD_SECONDS.

The readiness probe in the manifests repo must be repointed at /health/ready
before or together with this change, otherwise pods report Ready while the
selector map is still empty.

Refs PLA-1953

* fix: Keep decoding when the contract lookup fails

A decode request carrying `to` reads the address specific ABI from the
database, both in get_abi_function and in get_decoding_accuracy. With the
database unreachable those reads raised and the request returned 500, even
th... (continued)

Coverage Stats

66 of 87 new or added lines in 5 files covered. (75.86%)

3 existing lines in 2 files now uncovered.

1402 of 1545 relevant lines covered (90.74%)

0.91 hits per line