Skip to main content
Defined in: user/types.ts:12 Options for UserData.set and UserData.update.

​
Properties

​
ttl?

Defined in: user/types.ts:34 Time-to-live of the TOP-LEVEL key being written: a duration string accepted by parseDuration ('90s', '30m', '12h', '7d', '2w') or milliseconds. Must be positive and finite, and small enough that the expiry stays a safe-integer epoch (about 285,000 years; omit ttl for a permanent key), otherwise the call rejects with UserDataError('INVALID_TTL'). Fractional milliseconds are rounded up, so every store receives an integer expiry. Expiry rules (same model as Redis SET vs. a partial update):
  • with ttl — the top-level key expires ttl after this write, even when the path is nested (set('board.turn', 'x', { ttl: '30m' }) re-arms the expiry of board);
  • top-level write without ttl (set('board', …)) replaces the value AND clears any previous expiry — the key becomes permanent;
  • nested write without ttl (set('board.turn', …), delete('board.turn')) keeps the current expiry of the top-level key.
An expired key reads as absent immediately; stores remove it physically later (Redis natively, the others through purgeExpiredUserData).