Nesting Levels have exceeded supported limits

En bref — DynamoDB te permet d'imbriquer des types document (map M et list L) les uns dans les autres jusqu'à 32 niveaux de profondeur. Une structure plus profonde est rejetée avec une ValidationException. Aplatis le modèle de données, scinde la branche profonde en un élément séparé, ou stocke le sous-arbre trop profond sous forme d'une seule chaîne sérialisée.

Ce que ça signifie

ValidationException: 1 validation error detected: Nesting Levels have exceeded supported limits

# what the engine actually returns, reproduced against DynamoDB Local:
ValidationException: 1 validation error detected: Nesting Levels have exceeded supported limits: Attributes in the item have nested levels beyond supported limit

(C'est la formulation qu'AWS documente pour cet échec de validation ; la formulation exacte peut varier légèrement selon l'opération.) Une valeur d'attribut peut être un scalaire, ou une map/list qui contient elle-même d'autres valeurs — et DynamoDB plafonne cette imbrication à 32 niveaux. Le même plafond s'applique aux expressions : la profondeur maximale d'un chemin de document est de 32, donc tu ne peux pas non plus référencer plus profond que cela. La limite compte la profondeur des maps et des lists, pas le nombre d'attributs. La dépasser est un HTTP 400 ValidationException, détecté au moment de la validation, et non réessayable tant que le document n'est pas restructuré.

Pourquoi ça arrive

Des données profondément récursives — des structures d'arbre/graphe (organigrammes, fils de commentaires, catégories imbriquées) sérialisées en maps dans des maps au-delà de 32 niveaux.
Un sérialiseur générique — du code qui marshale un JSON imbriqué arbitraire directement dans les types document de DynamoDB sans garde-fou de profondeur.
Une auto-imbrication accidentelle — un bug qui enveloppe un élément à l'intérieur de lui-même de façon répétée.
Des documents migrés depuis une base de données documentaire dont l'imbrication n'a jamais été bornée.

Comment le corriger

Aplatis le modèle — remonte les sous-structures profondes en attributs de premier niveau ou en une disposition à clé composite, plutôt que des maps toujours plus profondes.
Scinde en plusieurs éléments — modélise la branche profonde sous forme d'éléments séparés sous la même clé de partition (le motif d'adjacence mono-table).
Sérialise le sous-arbre profond — stocke la portion trop profonde sous forme d'un attribut chaîne JSON unique (opaque pour DynamoDB, donc sa profondeur interne ne compte plus) si tu n'as pas besoin d'y faire des requêtes.
Ajoute un garde-fou de profondeur dans ta couche de marshalling pour que les documents ne puissent pas grossir silencieusement au-delà de la limite.

Mesure dans DynoTable

Inspecte les attributs imbriqués dans DynoTable avant de les écrire — ouvre un élément avec ⌘K et déplie les champs map/liste dans la visionneuse JSON pour voir jusqu'où descend la structure. Le staging (⌘S) te laisse prévisualiser un put/update et attraper les erreurs de profondeur avant validation.

Sers-toi du calculateur de taille d'élément en parallèle des contrôles de profondeur — une imbrication profonde pousse souvent les éléments vers le plafond des 400 Ko aussi. Change de profil avec ⌘P quand tu testes contre Local plutôt que contre AWS. Configuration : Se connecter à AWS, Installation.

Sources

Constraints in Amazon DynamoDB (vérifié le 2026-07-13)
Referring to item attributes when using expressions (vérifié le 2026-07-13)

Erreurs liées

Item size has exceeded the maximum allowed size — la limite distincte de 400 Ko sur l'élément entier.
An expression attribute name used in the document path is not defined — une erreur de référence de chemin de document.
ValidationException (aperçu)
Apprends : Types de données DynamoDB

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.