kobotoolbox / kpi / 36392937532

83%

master: 76%

push

github

perf(billing): compute usage balances once per limit check DEV-926 (#7637)

### 📣 Summary
Checking whether a project owner is over their plan limit now does less
repeated work in some submission paths.

### 📖 Description
When a submission comes in, the server checks whether the project owner
is over their submission or storage limit. Some paths, like imports and
backups, worked out the owner's usage more than once for the same check.
They now do it once. Which submissions get accepted or refused stays the
same.

### 💭 Notes
- New `check_exceeded_limits(user, usage_types)` checks several usage
types in one call and computes fresh balances at most once, only when a
type gets past its 15-min gate. `check_exceeded_limit` stays as a thin
wrapper for the NLP trackers and LRM 0011.
- In a web request, `@cache_for_request` already deduplicated the two
calls, so nothing changes there. Outside a request (imports, backups,
briefcase) that memo does nothing, and main computes twice.
- Counters on the 402 path still come from a fresh read, not from the
cached balances that decided the 402. Storage can drop (file deletes)
without clearing that cache, and storage counters drive attachment
auto-delete. `test_over_limit_rejection_counts_on_fresh_usage` covers
it.

### 👀 Preview steps
Backend only. Watch how many times usage gets computed for one refused
submission outside a web request.
1. ℹ️ have a project whose owner is over their submission limit
2. submit to it without the request middlewares (like an import does)
and get a 402
3. 🔴 [on main] usage computed 3 times
4. 🟢 [on PR] computed 2 times, same 402
5. 🟢 `test_check_exceeded_limits_computes_balances_once` and
`test_over_limit_rejection_counts_on_fresh_usage` cover it

10448 of 13809 branches covered (75.66%)

26 of 31 new or added lines in 2 files covered. (83.87%)

33335 of 40126 relevant lines covered (83.08%)

5.51 hits per line