decentraland / comms-gatekeeper / 35044858588

87%

Build Type

push

github

Committed by web-flow

Commit Message

feat: keep the active platform bans in memory instead of caching access decisions (#295)

* feat: keep the active platform bans in memory instead of caching access decisions

The access gate cached each decision for ACCESS_GATE_CACHE_TTL_MS so the
cluster feed would not cost two database reads per event, and then had to
defend that cache against every way a ban could land around it: a stale
allow after a ban, a fill racing an invalidation, a hit racing a bump, a
lookup straddling a ban. Each fix was correct and each added a check.

Bans are few, slow-changing, and written by this service, so the hot path
now reads them from memory. A ban registry adapter loads the active bans at
start, reloads them every BAN_REGISTRY_REFRESH_MS, and answers a connection
lookup as the database query would: own ban over a device match, newest
first, expiry honoured at read time. It decorates the user-moderation
database component, so every ban or lift written through that component
updates memory before anything else is told, whatever path wrote it. A
"not banned" answer is trusted, since that is the common case and what the
registry exists to make free. A "banned" answer is confirmed against the
table first, so a ban lifted or deleted behind the service's back can never
keep a wallet out; the read is one per event of a banned wallet. Until the
first successful load, lookups fall back to the table.

The gate is back to a plain lookup with its one fail-open policy, the cache
instance and the moderation epoch are gone, and user moderation knows
nothing about any of it. The device resolution read remains; it is the
only read left on the mint path. Single replica: a ban made through this
process reaches its lookups at once, and the reload bounds what another
replica would miss.

Covered by adapter specs for loading, precedence, expiry, add and remove,
a failed load with fallback and recovery, a failed refresh keeping the
previous contents, and stop; decorator specs for writ... (continued)

Coverage Stats

1332 of 1647 branches covered (80.87%)

Branch coverage included in aggregate %.

121 of 123 new or added lines in 8 files covered. (98.37%)

31 existing lines in 5 files now uncovered.

3593 of 3986 relevant lines covered (90.14%)

84.15 hits per line