La API de búsqueda de Zoho Desk devuelve un error HTTP 500 cuando modifiedTimeRange incluye la marca de tiempo exacta 2026-03-08T02:00:00.000Z; el fallo es reproducible solo en ese límite, mientras que los rangos adyacentes tienen éxito. [1]
Qué significa
La llamada GET /api/v1/tickets/search está provocando un error interno del servidor dentro de Zoho Desk cuando el parámetro modifiedTimeRange abarca o incluye 2026-03-08T02:00:00.000Z. El informe de la comunidad muestra que la misma llamada tiene éxito para rangos inmediatamente antes y después de esa marca de tiempo exacta, y falla con {"errorCode":"INTERNALSERVERERROR","message":"An internal server error occurred while performing this operation."} cuando el límite incluye la marca de tiempo. [1]
Causas comunes
- Un error de análisis o límite de fecha/hora del lado del servidor en la rutina de búsqueda que se activa solo para esa marca de tiempo UTC exacta. [1]
- Un caso extremo de registro indexado donde un registro o entrada de índice tiene un valor corrupto o inusual exactamente en esa marca de tiempo. [1]
- Una regla en el pipeline de búsqueda (ordenación, filtrado o agregación) que falla en ese valor límite. El informe muestra que eliminar sortBy o from no evitó el error. [1]
- Un comportamiento de transición de reloj/zona horaria a nivel de plataforma o manejo de segundos intercalados que produce un estado no manejado en ese instante. [1]
Cómo solucionarlo
- Solución a corto plazo: evita llamar a modifiedTimeRange que incluya 2026-03-08T02:00:00.000Z. Consulta rangos que terminen en 2026-03-08T01:59:59.999Z o comiencen en 2026-03-08T02:00:00.001Z para evitar el límite. [1]
- Estrategia de reintento: si debes cubrir el límite, divide la solicitud en dos consultas (antes y después de la marca de tiempo exacta) y fusiona los resultados del lado del cliente. Usa
limity paginación para mantener cada consulta pequeña. [1] - Reproducir y capturar diagnósticos: ejecuta los tres casos de prueba a continuación y recopila pares completos de solicitud y respuesta (URL, cadena de consulta, encabezados con Authorization enmascarado, cuerpo de respuesta y marcas de tiempo):
- Caso de éxito antes del límite: modifiedTimeRange=2026-03-08T01:58:00.000Z,2026-03-08T01:59:59.000Z (esperado 204). [1]
- Caso de fallo al alcanzar el límite: modifiedTimeRange=2026-03-08T01:59:59.000Z,2026-03-08T02:00:00.000Z (devuelve 500). [1]
- Caso de éxito después del límite: modifiedTimeRange=2026-03-08T02:00:00.000Z,2026-03-08T02:00:01.000Z (esperado 204). [1]
- Abre un ticket de soporte de Zoho Desk con: tu ID de organización, las tres solicitudes de reproducción anteriores, cuerpos de respuesta completos, marcas de tiempo y la llamada API exacta (GET /api/v1/tickets/search). Pide al soporte que revise los registros del servidor para esa marca de tiempo UTC y para cualquier error de índice o análisis. La publicación de la comunidad ya documenta el fallo reproducible, lo que acelera la investigación. [1]
- Monitorea un parche de plataforma: una vez que el soporte confirme la causa raíz, programa un cambio del trabajo de solución alternativa a las consultas normales después de que confirmen la corrección.
Cuándo escalar
Si el límite bloquea los flujos de trabajo de producción o no puedes evitarlo mediante