Generación de imágenes con Gemini usando prompt

Describe el problema/error/pregunta

Hola a todos,
Estoy enfrentando un problema con un comportamiento de ejecución tipo anidado dentro de un nodo Loop Over Images.

Mi configuración:

  1. Loop Over Images: Procesa una lista de imágenes obtenidas de Google Drive una por una (Batch Size = 1).
  2. Dentro del Loop: Para cada imagen, crea una carpeta (Create Concept Folder) y descarga el archivo de imagen.
  3. Expansión de elementos: Luego, un nodo de Código (Build Prompts) toma los datos de una sola imagen y genera 6 variaciones de prompts diferentes (expandiendo exitosamente 1 elemento entrante en 6 elementos salientes).
  4. Procesamiento: Los nodos posteriores (Gemini data, HTTP Request, Upload Concept Image) se ejecutan 6 veces perfectamente para la primera imagen.
  5. Retorno del Loop: Al final de la cadena de ejecución, uso un nodo Limit configurado con Max Items = 1 para reducir los 6 elementos nuevamente a exactamente 1 elemento antes de alimentarlo de vuelta al puerto de entrada Loop Over Images.

El problema:

  • La primera iteración funciona sin problemas (crea la carpeta, genera y carga las 6 imágenes de concepto).
  • En la segunda iteración (para la segunda imagen), el loop se activa correctamente, y el nodo Create Concept Folder se ejecuta exitosamente.
  • Sin embargo, justo después de crear la carpeta, el flujo de trabajo se detiene completamente. Los nodos posteriores (Download Image, Build Prompts, etc.) no se ejecutan en absoluto para el segundo elemento.
    Parece que n8n pierde el seguimiento de la secuencia de ejecución o del índice de elemento durante la segunda iteración del loop, incluso aunque el recuento de elementos se expandió de 1 a 6 dentro del cuerpo del loop, a pesar de que usé un nodo Limit para devolver exactamente 1 elemento al contador del loop.
    ¿Cómo puedo restablecer correctamente el contexto/índice de elementos dentro del loop para que la segunda iteración se ejecute completamente?
    (Nota: estoy adjuntando la captura de pantalla del diseño de mi flujo de trabajo a continuación)

¿Cuál es el mensaje de error (si hay alguno)?

Por favor, comparte tu flujo de trabajo


(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)

Comparte la salida devuelta por el último nodo

Información sobre tu configuración de n8n

  • Versión de n8n:
  • Base de datos (por defecto: SQLite):
  • Configuración de n8n EXECUTIONS_PROCESS (por defecto: own, main):
  • Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):
  • Sistema operativo:

Hola, esto parece ser un problema de estructura de bucle más que algo que puedas solucionar “reiniciando” el índice del elemento. El nodo Limit solo reduce la cantidad de elementos que se pasan adelante; no restaura el contexto del elemento del bucle externo original. En n8n, la vinculación de elementos es importante cuando un nodo expande o transforma elementos, especialmente cuando las expresiones posteriores dependen de .item o datos del nodo anterior.

Yo lo reestructuraría como un bucle anidado adecuado:

Bucle externo: Loop Over Images
Create Concept Folder
Download Image
Build Prompts

Luego bucle interno: Loop Over Prompts
Gemini data
Generate Concept Image
Prepare Binary
Upload Concept Image
→ de vuelta a Loop Over Prompts

Después de que el Loop Over Prompts interno finalice, conecta su salida Done de vuelta al nodo Loop Over Images externo para que la siguiente imagen comience. No alimentes uno de los seis elementos de indicación/imagen generados de vuelta al bucle de imagen externo. El nodo Loop Over Items de n8n está diseñado para procesar lotes y luego continuar desde las rutas de bucle/listo, y los nodos a menudo procesan listas automáticamente, por lo que el recuento de elementos debe ser controlado por la estructura del bucle en lugar de ser parcheado con Limit.

Además, en el nodo Code Build Prompts, copia los campos de imagen/carpeta originales en cada uno de los 6 elementos de indicación generados, por ejemplo imageId, imageName, folderId, y la ruta del archivo descargado. De esta manera, el paso de carga no necesita depender de referencias de elementos de bucle externo frágiles. Si estás usando expresiones .item más adelante, asegúrate de que el nodo Code preserve la vinculación de elementos/pairedItem, porque n8n necesita ese vínculo cuando un elemento de entrada se convierte en múltiples elementos de salida.

¡Hola @Gokhan_ARSLANTAS, bienvenido!
Puedes eliminar el bucle completamente. Create Concept Folder ya se ejecuta una vez por cada imagen entrante, así que alimenta la lista de archivos de Drive directamente en él, y luego deja que un nodo Code emita cada combinación de imagen x prompt como elementos planos (2 imágenes, 6 prompts = 12 elementos), cada uno llevando su propio folderId, fileId y prompt:

const scenarios = ['scenario 1', 'scenario 2', 'scenario 3', 'scenario 4', 'scenario 5', 'scenario 6'];
const images = $('List Images').all();

return $input.all().flatMap((folder, i) => scenarios.map((s, n) => ({
  json: {
    folderId: folder.json.id,
    fileId: images[i].json.id,
    filename: `${images[i].json.name}-v${n + 1}.png`,
    prompt: `${images[i].json.name}, ${s}`
  }
})));

Reemplaza List Images por el nombre de tu nodo de lista de Drive. Download Image, Gemini data, HTTP Request y Upload Concept Image se ejecutan entonces cada uno una vez por elemento, así que toda la cosa es una línea recta sin nodo de bucle y sin ningún borde realimentándose a nada.
Si la API de imágenes te aplica límites de velocidad, acelera el nodo HTTP Request con Add Option > Batching (Items per Batch = 1, Batch Interval = 1000) en lugar de volver a meter un bucle.

Hola James, Muchas gracias por tu retroalimentación. Lo intenté pero no puedo resolver el problema. También estoy recibiendo ayuda de un agente de IA para ingresar información en los nodos. Quizá por eso no pueda hacerlo. Saludos cordiales

Estimado Anshul, voy a intentarlo ahora. Gracias por tu retroalimentación. Por lo tanto, estoy usando por imagen 6 indicaciones diferentes. No hay dos imágenes de entrada al mismo tiempo. ¿Tu solución sigue siendo válida?

Hola @Gokhan_ARSLANTAS
Sí. Una imagen solo significa que el nodo Code emite 6 elementos en lugar de 12, y Download Image, Gemini data, HTTP Request y Upload Concept Image se ejecutan cada uno 6 veces. Nada más cambia.
Si siempre es exactamente una imagen, puedes eliminar el emparejamiento de índices y mantenerlo plano:

const scenarios = ['scenario 1', 'scenario 2', 'scenario 3', 'scenario 4', 'scenario 5', 'scenario 6'];
const image = $('List Images').first().json;
const folderId = $input.first().json.id;

return scenarios.map((s, n) =
  {
  json: {
    folderId,
    fileId: image.id,
    filename: `${image.name}-v${n + 1}.png`,
    prompt: `${image.name}, ${s}`
  }
}));

Deja el nodo Code en Mode: Run Once for All Items, que es el predeterminado, ya que el código devuelve todo el arreglo de 6 elementos en sí mismo.

Confirmo el diagnóstico de James, es exactamente el problema clásico de mezclar niveles de loop en n8n.

El Limit node no “resetea” nada del contexto del loop exterior — solo filtra cuántos items pasan. El Loop Over Images sigue esperando que el flujo que vuelve a su input tenga la misma “forma” (linaje de items) que el que salió, y cuando metes un Code node que expande 1→6 en medio, rompes ese linaje aunque luego lo reduzcas a 1 con Limit.

La solución de loop anidado que propone James es la correcta. Un par de cosas a vigilar cuando lo implementes:

  • En el Code node Build Prompts, asegúrate de devolver explícitamente pairedItem en cada uno de los 6 items generados, apuntando al índice del item original. Si no, cualquier expresión posterior que dependa de datos del item padre (imageId, folderId, etc.) puede fallar de forma silenciosa en vez de dar error.
  • El loop interior (Loop Over Prompts) necesita su propio Batch Size bien configurado — si lo dejas en el mismo tamaño que el exterior por error de copy-paste, vuelves a tener el mismo síntoma.
  • Verifica que el output “Done” del loop interior (no el “Loop”) sea el que conecta de vuelta al exterior — es un error común conectar el puerto equivocado y quedarse pillado en un bucle infinito o corto.

Con esto debería resolverse la segunda iteración en adelante.