Su historial de automatización muestra una ejecución exitosa y un paquete de salida. Facebook muestra dos publicaciones.

Esa evidencia descarta algunas explicaciones simples, pero no prueba qué sistema duplicó la escritura. No vuelva a ejecutar la automatización. Conserve los originales de ambos proveedores y cree una fila de evidencia para cada escritura que pueda haber llegado a Facebook.

Esta lista de verificación cubre el caso específico en el que un flujo de trabajo Airtable, Make, n8n o personalizado parece ejecutarse una vez mientras una página de Facebook recibe publicaciones duplicadas.

La respuesta corta

Antes de cambiar el escenario, registre:

  1. el ID de ejecución de la automatización y la hora exacta de inicio/finalización
  2. cada paquete de entrada o ID de registro fuente
  3. historial de reintentos, ejecución incompleta y tiempo de espera
  4. cada ID de publicación de Facebook y enlace permanente
  5. la marca de tiempo pública y el contenido renderizado de cada publicación

Si las dos publicaciones de Facebook tienen ID de proveedor diferentes, hubo dos creaciones del lado del proveedor incluso si la interfaz de usuario de automatización resume el trabajo como una sola ejecución. La pregunta restante es dónde se originó la segunda creación: otro desencadenante, un reintento automático, una recuperación de tiempo de espera, un duplicado del lado del proveedor o un cliente separado que utiliza el mismo registro de origen.

No etiquete la causa hasta que la evidencia distinga esos caminos.

1. Conserve primero ambos originales públicos

Abra ambas publicaciones de Facebook antes de eliminar o editar cualquiera de ellas. Para cada publicación, capture:

  • Identidad de la página
  • ID de publicación del proveedor
  • enlace permanente
  • marca de tiempo publicada
  • subtítulos y medios exactos
  • cualquier autor visible o atribución editorial

Compare la huella digital del texto y los medios. Dos títulos idénticos no prueban que se haya repetido la misma solicitud; dos clientes independientes pueden enviar el mismo registro fuente. Dos ID de proveedor diferentes prueban que el proveedor aceptó dos creaciones.

Si solo hay un enlace permanente disponible y la segunda publicación aún está visible, conserva una captura de pantalla y la marca de tiempo pública mientras investigas. Marque el ID que falta como unknown.

2. Separar la ejecución de un escenario de la escritura de un proveedor

Una ejecución de automatización ecológica significa que la orquestación se completó según las reglas de esa plataforma. No significa necesariamente que se haya producido una escritura externa.

Cree documentos que indiquen que las fallas de conexión, límite de velocidad y tiempo de espera se puedan reintentar mediante ejecuciones incompletas y retrocesos exponenciales. Su documentación también señala que las acciones en aplicaciones externas no transaccionales no se pueden revertir. Por lo tanto, la creación de un proveedor puede tener éxito incluso cuando un paso posterior del cliente agota el tiempo de espera o pierde la respuesta.

Compruébelos por separado:

Capa Pruebas a recopilar Lo que puede probar
Gatillo programación/hora del webhook e ID del activador cuantas ejecuciones se iniciaron
Fuente ID de registro de Airtable y recuento de paquetes de entrada cuantos registros entraron al flujo
Crear módulo funcionamiento del módulo, hora de inicio/finalización, salida bruta cuántas llamadas de proveedor registró la plataforma
Sistema de reintento ejecuciones incompletas, reintentos automáticos, historial de retrocesos si se volvió a ejecutar una llamada fallida o ambigua
Facebook cada ID de publicación y enlace permanente cuántos objetos de proveedor público existen

No colapses estas cinco filas en "la ejecución fue exitosa".

3. Compruebe si hay segundos desencadenantes ocultos

Antes de culpar a Facebook, elimina las causas que puedes controlar:

  • otro escenario programado usando la misma página
  • un webhook instantáneo más una búsqueda por horas
  • un segundo espacio de trabajo, entorno o escenario antiguo
  • dos registros fuente con el mismo contenido
  • una publicación manual realizada desde la página o Business Suite
  • una ventana de sondeo que selecciona un registro nuevamente antes de que su actualización de estado sea visible

Utilice identificadores estables, no sólo marcas de tiempo. Registre el ID del escenario de automatización, el ID del registro de origen, la huella digital del contenido y el ID de la página de destino en la misma fila.

Si dos flujos de trabajo comparten una tabla de origen, agregue un reclamo o bloqueo específico de destino antes de que el proveedor lo cree. Un margen de tiempo por sí solo no es una garantía de idempotencia.

4. Trate una respuesta lenta como ambigua

Un módulo de Facebook de larga duración es una prueba importante, pero no identifica la causa por sí solo.

Si el proveedor aceptó la publicación y el cliente agotó el tiempo de espera antes de recibir la respuesta, un reintento automático puede crear otra publicación a menos que la integración concilie el primer resultado. Si el módulo devolvió un ID de proveedor mientras existen dos publicaciones, conserve el ID de publicación que no coincide y pregunte qué actor lo creó.

La regla segura es:

Un tiempo de espera o una respuesta perdida es unknown, no failed, hasta que se verifique el destino.

Pausar la recuperación automática para ese destino cuando ya exista algún ID de proveedor o publicación pública coincidente.

5. Cree un libro de pruebas de dos puestos

Utilice una fila por objeto de proveedor:

destination_page_id:
source_record_id:
automation_execution_id:
create_module_operation_id:
retry_or_incomplete_execution_id:
provider_post_id:
provider_permalink:
provider_timestamp:
content_fingerprint:
public_outcome:
observed_in_automation_output: yes | no | unknown

Para dos publicaciones de Facebook, el libro mayor debe contener dos filas incluso si la plataforma de automatización expone una ejecución. Los campos no coincidentes muestran dónde la investigación necesita pruebas más sólidas.

6. Agregue una puerta de recuperación con ámbito de destino

Antes de crear o reintentar, verifique el registro existente para esa página:

  1. ¿Existe ya una identificación de publicación del proveedor?
  2. ¿Existe un enlace permanente almacenado?
  3. ¿La página pública contiene una huella digital de contenido coincidente en el período de tiempo previsto?
  4. ¿Una ejecución incompleta aún es elegible para volver a intentar crear el módulo?

Cuando el resultado sea ambiguo, mueva el elemento a conciliación manual en lugar de crearlo nuevamente. Cuando un lote multicanal tiene éxito parcial, vuelva a intentarlo solo en el destino no resuelto después de verificar el estado de su propio proveedor.

Esta puerta no garantiza que cada proveedor exponga una clave de idempotencia. Evita que su lógica de recuperación trate la confirmación faltante del cliente como prueba de que no se creó nada.

Una advertencia real de éxito parcial de otra red

En un incidente separado de ANKK Threads, se publicó una raíz programada y el paso de respuesta encontró un resultado no disponible del proveedor. La recuperación automática produjo dos respuestas públicas idénticas a pesar de que el operador no realizó ningún reintento manual. Los originales del proveedor, el contenido estable y los job ID se conservaron para la investigación del producto.

Ese incidente de Threads no prueba la causa de un duplicado de Facebook. Demuestra el límite general del fracaso: una vez que cualquier segmento puede haber llegado al proveedor, la recuperación necesita la conciliación del proveedor en ese segmento en lugar de una repetición ciega de toda la operación.

Fuentes y próximos pasos

Yo opero ANKK. ANKK no incluye un escritor de IA incorporado. Conecta contenido preparado por personas, herramientas de inteligencia artificial externas o scripts con programación social, estados a nivel de canal y verificación provider original.

Revise el flujo de trabajo del desarrollador ANKK