DynamoDB TTL attribute must be a Number

In breve — Il Time to Live di DynamoDB elimina un Item solo quando il suo attributo TTL designato contiene un Number che rappresenta un timestamp epoch Unix in secondi. Una String come "1735689600", un valore in millisecondi, una data ISO-8601, o un attributo mancante vengono silenziosamente ignorati — l'Item non scade mai. Memorizza il TTL come un Number in secondi epoch e riscrivi gli Item interessati.

Cosa significa

# A second UpdateTimeToLive call within one hour of the first raises:
ValidationException  (TTL settings can only be modified once per table per hour)

# The quieter failure — no error at all, item just never expires:
TTL attribute "expiresAt" = "2026-01-01T00:00:00Z"   ← String, ignored
TTL attribute "expiresAt" = 1735689600000            ← milliseconds: tens of thousands of years away

Abilitare il TTL (UpdateTimeToLive) riesce anche quando l'attributo non esiste ancora o è del tipo sbagliato — DynamoDB non ne controlla il tipo in anticipo. Il fallimento si manifesta più tardi: il processo TTL in background elimina un Item solo quando l'attributo è un Number che contiene un timestamp epoch Unix in secondi nel passato (e non più di cinque anni nel passato). Qualsiasi altra cosa è trattata come "nessuna scadenza".

Perché succede

Memorizzato come String — il valore è {"S": "1735689600"} invece di {"N": "1735689600"}. Il TTL ignora i tipi non-N.
Millisecondi invece di secondi — Date.now() (JavaScript) restituisce millisecondi; un valore di 13 cifre è decine di migliaia di anni nel futuro, quindi l'Item di fatto non scade mai.
Una stringa data ISO-8601 / leggibile invece dei secondi epoch.
Un timestamp più vecchio di cinque anni nel passato — il processo TTL lo ignora invece di eliminare l'Item.
Un nome di attributo diverso da quello registrato con il TTL (il nome è case-sensitive).
Chiamare UpdateTimeToLive di nuovo troppo presto — la modifica richiede fino a un'ora per essere completamente elaborata, e qualsiasi chiamata UpdateTimeToLive aggiuntiva per la stessa tabella durante quell'ora genera una ValidationException.

Come risolverlo

Scrivi il valore TTL come un Number in secondi epoch — Math.floor(Date.now() / 1000) + ttlSeconds in JavaScript, int(time.time()) + ttl in Python. Non memorizzare mai millisecondi.
Usa il tipo N, non S. Con il client di basso livello è {"N": "1735689600"}; il Document Client marshalla un numero nativo per te.
Fai corrispondere esattamente il nome dell'attributo registrato, incluse maiuscole/minuscole. Confermalo con DescribeTimeToLive.
Riempi gli Item esistenti — gli Item scritti prima della correzione portano ancora il valore errato; riscrivili con un Number in secondi epoch corretto.
Attendi un'ora tra le modifiche di configurazione TTL — UpdateTimeToLive richiede fino a un'ora per elaborare, e ulteriori chiamate durante quella finestra vengono rifiutate con una ValidationException.

Vuoi vedere il tipo wire di ogni attributo mentre sfogli una tabella? L'app desktop DynoTable mostra i tag di tipo N/S/M inline, così un TTL memorizzato come String salta all'occhio prima che ti costi un Item non scaduto.

FAQ

Perché il mio TTL DynamoDB non elimina gli Item? L'attributo TTL deve essere un Number che contiene un timestamp epoch Unix in secondi. Un valore String, un valore in millisecondi, una data ISO, o un nome che non corrisponde all'attributo TTL registrato vengono tutti silenziosamente ignorati, quindi l'Item non scade mai. L'eliminazione non è nemmeno immediata — DynamoDB rimuove tipicamente gli Item scaduti entro qualche giorno dalla loro ora di scadenza.

DynamoDB valida il tipo dell'attributo TTL quando abilito il TTL? No. UpdateTimeToLive riesce anche se l'attributo è mancante o del tipo sbagliato. Il requisito di tipo (Number, secondi epoch) è imposto solo dal processo di eliminazione in background, ed è per questo che un TTL errato fallisce in silenzio.

Errori correlati

Float / decimal number types not supported — una trappola correlata di tipizzazione numerica.
ValidationException (overview)
Impara: DynamoDB TTL · DynamoDB data types

Riferimenti

Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra.