Discussions

Hola, somos una inmobiliaria (company_id 45816) que usa el property_importer para sincronizar nuestro catálogo propio (armamos y servimos nosotros mismos el feed JSON, alojado en nuestro servidor). Venimos teniendo un problema intermitente desde hace varios meses, que hasta ahora no pudimos resolver de nuestro lado por más que revisamos y reforzamos todo el proceso de disparo del import.

El problema

De forma esporádica e impredecible (a veces pasan semanas sin que ocurra, otras veces varias veces en la misma semana), el property_importer deshabilita propiedades que estaban activas — a veces la gran mayoría o directamente el catálogo entero — sin que aparezca ningún error ni alerta que lo explique, y sin que nuestro servidor haya recibido ningún pedido GET al feed en esa ventana (lo confirmamos revisando el access log de nuestro propio servidor entre el momento en que disparamos el import y el momento en que llega el callback: cero requests a la URL del feed).

Ejemplo real medido con nuestro propio monitoreo (comparamos cuántas propiedades deberíamos tener activas, según nuestro feed, contra cuántas ve la API pública de Tokko como activas en cada momento):

15:00 activas=73 esperadas=83
16:00 activas=0 esperadas=84 <- caída total
17:00 activas=0 esperadas=84
18:00 activas=0 esperadas=84
19:00 activas=0 esperadas=84
20:00 activas=0 esperadas=84
21:00 activas=44 esperadas=84 <- empieza a recuperarse solo (sin ninguna causa aparente)
22:00 activas=84 esperadas=84 <- vuelve a la normalidad (aca hice modificaciones manuales para que tome las 84 propiedades)

Ninguna de esas horas coincide con ningún cambio de nuestro lado — no tocamos el catálogo, no cambiamos el feed, no re-disparamos nada manualmente. El catálogo simplemente se cae y, unas horas después, vuelve a estar completo solo, sin que sepamos por qué pasó ni por qué se corrigió.

El callback que recibimos en esos casos

Cuando pasa esto, el callback que llega a nuestra callback_url tiene esta forma (ejemplo real, con el token reemplazado por xxxx):

POST /nuestro-callback?import_id=58225&cb=1788462003&token=xxxx

{
"errors_list": [],
"updated_list": [],
"disabled_list": ["1277","2017","1081","934","1976","1978","1278","1974","1893","1994",
"2032","2027","2042","1975","1926","1970","2006","2023","1998","2015",
"2038","2035","2030","1999","2040","2045","2060","2055","2057","64",
"533","920","2064","2063","2065","2066","2067","2068"],
"files_errors_list": [],
"alerts_list": [],
"company_id": 45816,
"not_updated_list": [],
"created_list": []
}

Es decir: disabled_list viene con decenas de reference_code reales de nuestro catálogo, pero errors_list, alerts_list, updated_list, created_list y files_errors_list vienen TODOS vacíos. No hay ningún error de validación, ningún alert, nada que indique qué salió mal — simplemente se deshabilitan propiedades que un momento antes estaban perfectas.

Lo que ya descartamos de nuestro lado

Para no hacerles perder tiempo con hipótesis que ya verificamos:

No es un problema del feed en sí. El mismo feed, pedido manualmente en el momento del incidente, siempre respondió bien (200, JSON válido, con todas las propiedades). Además, como dijimos, el import "fantasma" ni siquiera llega a pedir el feed — no puede ser un problema de contenido si nunca lo leyeron.
No es por imports superpuestos de nuestro lado. Al principio sospechamos que estábamos disparando dos imports en paralelo y que uno pisaba al otro con una foto vieja del catálogo (el reemplazo de property_importer es total, no incremental). Implementamos un debounce (agrupamos cualquier cantidad de cambios seguidos y disparamos como máximo un import cada tantos minutos) y un guardián que espera el callback real del import anterior antes de disparar uno nuevo. Con las dos protecciones activas, el problema siguió apareciendo igual — así que no es (o no es solo) un tema de solapamiento de nuestro lado.
No es por attributes/status mal enviados ni por errores de validación del payload — si fuera eso, aparecería en errors_list o alerts_list, y esos vienen vacíos siempre que pasa esto.
Lo que armamos como paliativo (no como solución)

Como no pudimos evitarlo, armamos una auto-recuperación de nuestro lado: cuando detectamos este patrón exacto (disabled_list con contenido + el resto de las listas vacías, sin haber recibido ningún GET a nuestro feed), esperamos un rato y volvemos a disparar el import — eso, tarde o temprano, termina restaurando el catálogo. Pero es un parche: no sabemos qué lo causa, no podemos predecir cuándo va a volver a pasar, y mientras tanto nuestras propiedades quedan invisibles en Tokko/los portales durante un rato (a veces minutos, a veces varias horas, como en el ejemplo de arriba) sin que hagamos nada distinto.

Lo que necesitamos

¿Es un problema conocido del lado de Tokko? ¿Hay alguna cola/worker interno del property_importer que a veces "confirme" un import sin haber llegado a procesarlo de verdad?
¿Podrían revisar de su lado, con los import_id reales que tenemos en nuestros logs (podemos pasarlos por privado si hace falta), qué pasó puntualmente en esos imports — por qué se deshabilitaron esas propiedades sin ningún error/alert asociado?
¿Hay alguna forma de que nuestro callback_url reciba más detalle cuando pasa esto (motivo del disabled, no solo la lista de IDs)?
Cómo armamos nuestro feed (por si ayuda a descartar algo del lado del payload)

No podemos compartir la URL real del feed en un foro público (tiene un token de acceso), pero sí les paso cómo lo armamos y un ejemplo real de un ítem completo (una sola propiedad), para que puedan ver el formato exacto que mandamos:

Nuestro feed es un JSON armado dinámicamente desde nuestra base de datos (no un archivo estático) — cada vez que Tokko lo pide, se genera al vuelo con el estado real del catálogo en ese momento.
Disparamos el import con un POST a https://www.tokkobroker.com/property_importer/ con body {"url": "<nuestra_url_de_feed>?token=xxxx&cb=

[ {
"reference_code": "613",
"updated_at": "2026-09-08 14:23:17",
"property_type": 2,
"operations": [
{ "type": "3", "prices": [{ "currency": "ARS", "price": 218000, "period": "1" }] }
],
"street": "BUENOS AIRES",
"number": "1931",
"floor": "4",
"appartment": "A",
"apartment": "A",
"location": 26641,
"description": "Tres Ambientes A La Calle Con Balcón Corrido... (recortado)",
"publication_title": "Departamento - BUENOS AIRES 1931",
"age": 0,
"images": [
{ "url": "https://www.berasueta.com/_lib/file/img/FOTOS/613/IMG_6943.JPG", "description": "", "is_blueprint": false },
{ "url": "https://www.berasueta.com/_lib/file/img/FOTOS/613/IMG_6940.JPG", "description": "", "is_blueprint": false }
],
"attributes": [
{ "code": "network_share", "value": "0" },
{ "code": "disposition", "value": "2" },
{ "code": "property_condition", "value": "Reciclado" },
{ "code": "parking_lot_amount", "value": "1" },
{ "code": "room_amount", "value": "3" },
{ "code": "suite_amount", "value": "2" },
{ "code": "bathroom_amount", "value": "2" },
{ "code": "total_surface", "value": "60" },
{ "code": "bed_amount", "value": "4" }
],
"services": [1504],
"producer_user": "[email protected]",
"branch": "[email protected]"
}
]
Este mismo formato lo usamos para las tres operaciones que publicamos (Venta = type "1", 24 meses = type "2", Temporario = type "3"), y venía funcionando bien en imports normales — el problema no parece estar en el contenido del feed, sino en algo que pasa (o no pasa) del lado del property_importer antes de siquiera llegar a pedirlo.

Cualquier ayuda para entender la causa de fondo se agradece — llevamos meses conviviendo con esto y el parche de auto-reintento nos tapa el síntoma, pero no nos deja tranquilos de cara a un incidente más largo.

Gracias de antemano.