Los datos ya existen en la base de datos, así que esto no es una condición de carrera con una inserción reciente.
Lo que me confunde es que nada cambia entre la primera y la segunda ejecución, sin embargo la segunda ejecución consistentemente funciona.
¿Alguien ha encontrado este tipo de comportamiento “primera ejecución falla, segunda ejecución funciona” con nodos MongoDB? ¿Podría estar relacionado con tipos de datos (como ObjectId versus string), tiempo de evaluación de expresiones, estado de ejecución, u otro aspecto específico de n8n?
Debes asegurar que el Campaign_ID se pase como un ObjectId.
La forma más confiable de manejar ObjectId en n8n es crear el objeto de consulta en un nodo de Código. Esto evita que n8n convierta accidentalmente tus IDs a cadenas de texto.
Añade un nodo de Código antes de tu segundo nodo de MongoDB.
Usa este código:
const leadUserId = $('Edit Fields').first().json.body.args.LeadUserID;
const campaignId = $json._id;
return {
query: {
Customer_ID: leadUserId,
Campaign_ID: { "$oid": campaignId } // Esto le indica a MongoDB que lo trate como un ObjectId
}
};
En tu nodo de MongoDB, en lugar de escribir el JSON manualmente, referencia la salida del nodo de Código: {{ $json.query }}
@alee_Ostovar
Tuve un problema muy similar con Postgres. Por lo que pude determinar, tenía que ver con datos fijados en el disparador, particularmente si el disparador es un webhook o un disparador de “Cuando se ejecuta por otro flujo de trabajo”. Aunque no se supone que suceda, los datos fijados del disparador se estaban pasando aguas abajo durante las ejecuciones en producción y a veces esos datos son incorrectos o simplemente un valor nulo de pruebas manuales. Y luego cuando abres manualmente la ejecución que falló, los datos fijados del disparador se sobrescriben y mágicamente funciona.
Pude resolverlo asegurándome de desfijar siempre los datos del disparador antes de que mi flujo de trabajo se ponga en vivo. No ha vuelto a ocurrir desde entonces, y solía ocurrir aproximadamente el 50% de las veces anteriormente. Espero que esto te ayude.
Gracias por la sugerencia. En mi caso, Campaign_IDno está almacenado como un ObjectId de MongoDB. Está almacenado como una cadena en la colección Campaign_Members (es solo un valor de referencia, no un campo ObjectId real).
Por eso, envolverlo como { "$oid": campaignId } haría que la consulta buscara un ObjectId, lo que no coincidiría con el valor de cadena almacenado.
Gracias, en realidad ya lo intenté. Me aseguré de que el disparador Webhook no estuviera fijado, pero lamentablemente el comportamiento no cambió.
Una solución alternativa que encontré es reemplazar el nodo Edit Fields (Set) con un nodo Code que genere la misma salida. Con el nodo Code, el flujo de trabajo se comporta correctamente cada vez.
También noté otro problema que parece estar relacionado con el nodo Edit Fields: al pasar documentos de MongoDB a través de él, el _id de MongoDB a veces se convierte en un Buffer en lugar de mantener su forma original. Eso parece ser un problema separado con el nodo Set/Edit Fields en sí.
Por el momento, usar un nodo Code soluciona ambos problemas, pero parece más evitar el error que arreglarlo. Estoy intentando entender por qué el nodo nativo Set/Edit Fields se comporta de esta manera.
No creo que sea un error de tipo de datos, ya que ambas variables se almacenan como cadenas, y la consulta también utiliza valores de cadena. Si fuera un error de tipo, esperaría que fallara consistentemente en lugar de solo en la primera ejecución.
Pude resolver el problema reemplazando el nodo Edit Fields (Set) con un nodo Code. Eso funciona, pero estoy intentando entender por qué el nodo Set nativo exhibe este comportamiento en primer lugar.
Al envolver {{ $json._id }} entre comillas dobles, estás indicándole explícitamente a n8n que trate el Campaign_ID como una cadena. Cuando MongoDB recibe una cadena para un campo que se almacena como ObjectId, devuelve cero resultados porque una cadena no es igual a un ObjectId, aunque los caracteres sean idénticos.
Durante la primera ejecución manual, el nodo puede no resolver la expresión exactamente como se esperaba o fallar la consulta de BD. Sin embargo, durante la segunda ejecución, el editor a menudo utiliza la salida almacenada en caché del estado de ejecución anterior del nodo.
Esta es exactamente la parte confusa, y en realidad es el segundo problema que estoy enfrentando.
El nodo Edit Fields a veces pasa _id como [object Object], así que sospechaba que era un problema de tipo de datos. Para verificarlo, registré el valor usando un nodo Code inmediatamente después de un nodo de MongoDB (antes de un edit fields). Aquí está la salida:
En la superficie, parece ser una cadena primitiva. Sin embargo, dado el comportamiento que estoy viendo, sospecho que aún puede haber un contenedor BSON subyacente o algún tipo interno/proxy involucrado que no se refleja en la salida del nodo Code. Eso explicaría por qué el nodo de MongoDB posteriormente trata el valor como un objeto en lugar de una cadena.
Al envolver la expresión en String(), fuerza al motor de expresiones de n8n a ejecutar un casting de JavaScript antes de que el valor se pase al nodo de MongoDB. Esto elimina cualquier contenedor BSON, proxy o metadatos de objeto, asegurando que MongoDB reciba una cadena literal cada vez.
