Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Skip the write for a non-positive TTL instead of passing it to the cache backend
A negative or zero TTL is a common in-house convention for disable caching here, and some backends silently treat it as already-expired. Others reject it outright, so every such call burns a failed round trip and an error log. Short-circuit the write instead of forwarding the sentinel.
Bad example
| 1 | // caller: const ttl = -1; // disable caching in preview mode |
| 2 | set(key, value, ttl) { |
| 3 | if (ttl) { // -1 is truthy |
| 4 | client.setEx(key, ttl, value); // ERR invalid expire time |
| 5 | } |
| 6 | } |
Explanation (EN)
A truthiness check lets the disable sentinel through to a backend that rejects it, so the disabled path costs a failed call plus an error log on every request.
Objašnjenje (HR)
Provjera istinitosti propusta sentinel za iskljucivanje do pozadinskog servisa koji ga odbija, pa iskljuceni put na svakom zahtjevu kosta neuspjeli poziv i zapis greske.
Good example
| 1 | set(key, value, ttl) { |
| 2 | if (ttl <= 0) return; // caching disabled for this call |
| 3 | client.setEx(key, ttl, value); |
| 4 | } |
Explanation (EN)
The sentinel is handled where it means something, and the backend only ever sees a valid expiry.
Objašnjenje (HR)
Sentinel se obraduje ondje gdje nesto znaci, a pozadinski servis vidi samo valjano vrijeme isteka.
Notes (EN)
Grep for existing callers before changing a cache backend - a value the old backend tolerated is exactly the kind of thing a new one rejects, and the call site predates your change.
Bilješke (HR)
Prije zamjene pozadinskog cachea pretrazi postojece pozivatelje - vrijednost koju je stari servis tolerirao upravo je ono sto novi odbija, a poziv je stariji od tvoje promjene.