Votre symptôme (fonctionne pour l'image 1, l'image 2 n'obtient qu'un dossier et aucune génération) est le problème classique de Loop Over Items imbriquée. Ce n'est presque jamais le nœud Gemini.
Pourquoi cela se produit
La Loop Over Items (SplitInBatches) de n8n conserve son compteur de batch à l'intérieur du nœud. Votre boucle interne sur les 6 prompts se termine pour l'image 1 et reste dans l'état « done ». À la deuxième itération externe, votre boucle d'images lui envoie l'image 2, mais la boucle interne croit toujours qu'elle a déjà terminé, donc elle déclenche immédiatement sa sortie done et ignore les nœuds Gemini et upload. Tout ce qui se trouve en amont de la boucle interne continue de s'exécuter, ce qui explique exactement pourquoi l'image 2 n'obtient que son étape Create Concept Folder et rien d'autre.
Le correctif à un nœud
Ouvrez votre nœud interne Loop Over Prompts, allez à Options, et activez Reset. Cela force la boucle interne à se réinitialiser chaque fois qu'une nouvelle image arrive de la boucle externe au lieu de rester « done ». C'est le correctif pour la grande majorité des rapports « nested loop runs once ».
Deux choses méritent une vérification rapide pendant que vous êtes là :
- Confirmez que Build Prompts émet réellement 6 éléments par image. Si une exécution affiche un nombre total d'« items » inférieur à celui que vous attendez, la boucle a moins de choses à itérer que vous ne le pensez.
- La branche done de votre boucle interne devrait revenir à la boucle externe d'images, ce qu'elle fait dans votre capture d'écran, donc le câblage lui-même est correct. Reset est la pièce manquante.
À considérer : supprimer complètement la boucle interne
Les boucles SplitInBatches imbriquées sont le modèle le plus fragile de n8n, et vos appels Gemini s'exécutent strictement un à la fois, donc 2 images à 6 prompts chacune font 12 générations séquentielles. Puisque vous êtes sur nano-banana (Gemini 3.1 Flash Image), vous pouvez distribuer les 6 prompts comme 6 éléments et les exécuter en parallèle avec une API d'image asynchrone. J'utilise KIE.AI, qui expose nano-banana comme un job submit-then-poll :
- Build 6 Prompts (un nœud Code) émet 6 éléments.
- Submit Task est un seul nœud HTTP sans boucle autour. Parce qu'un nœud HTTP s'exécute une fois par élément d'entrée, les 6 jobs se déclenchent quasi-simultanément et chacun retourne un
taskId.
- Une courte étape Wait then Poll collecte chaque résultat. Les éléments s'acheminent d'eux-mêmes : un terminé télécharge et enregistre immédiatement, un en attente attend et ré-interroge, donc les jobs rapides n'attendent pas les lents.
Il n'y a pas de Loop Over Items interne n'importe où, donc il n'y a pas d'état reset à mal gérer, et les 6 se rendent tous à la fois au lieu d'un à la fois.
J'ai mis un workflow de référence épuré ci-dessous (cliquez sur </> dans le compositeur et il s'importe directement). La boucle d'image externe reste ; la boucle de prompt interne a disparu. Remplacez les nœuds Google Drive par l'endroit où se trouvent vos images, déposez votre credential bearer KIE.AI sur les deux nœuds HTTP, et modifiez les six chaînes de scénario dans Build 6 Prompts. Il y a également une note collante montrant la modification d'une ligne pour exécuter image-to-image (variations de l'image source) au lieu de text-to-image.
Chaque approche vous répare : Reset si vous voulez conserver votre conception actuelle, ou le fan-out asynchrone si vous le voulez plus rapide et plus difficile à casser à mesure que vous ajoutez plus d'images d'entrée.
J'espère que cela vous aide,
Michael
