Join our community: https://t.me/+DOylgFv1jyJlNzM0
Why this matters
claimable.service.ts caches claimable-amount computations (with TTL and cache-key issues already tracked separately). Beyond the key/TTL bugs, there's a functional question: does the cache get proactively invalidated the moment a TokensWithdrawn event is indexed, or does it only expire passively via TTL? If it's TTL-only, users could see a stale (too-high) claimable amount for up to the full TTL window right after withdrawing, which is a confusing UX regression distinct from the already-tracked cache-key bug.
Acceptance criteria
Files to touch
backend/tests/claimable.service.test.ts
backend/src/services/claimable.service.ts
Out of scope
- Fixing the cache-key/token-collision bug (tracked separately)
- Fixing the TTL-default inconsistency (tracked separately)
Why this matters
claimable.service.tscaches claimable-amount computations (with TTL and cache-key issues already tracked separately). Beyond the key/TTL bugs, there's a functional question: does the cache get proactively invalidated the moment aTokensWithdrawnevent is indexed, or does it only expire passively via TTL? If it's TTL-only, users could see a stale (too-high) claimable amount for up to the full TTL window right after withdrawing, which is a confusing UX regression distinct from the already-tracked cache-key bug.Acceptance criteria
Files to touch
backend/tests/claimable.service.test.tsbackend/src/services/claimable.service.tsOut of scope