La ricerca API di Zoho Desk restituisce un errore HTTP 500 quando modifiedTimeRange include il timestamp esatto 2026-03-08T02:00:00.000Z; il fallimento è riproducibile solo a quel limite, mentre gli intervalli adiacenti hanno successo. [1]
Cosa significa
La chiamata GET /api/v1/tickets/search sta riscontrando un errore interno del server all'interno di Zoho Desk quando il parametro modifiedTimeRange copre o include 2026-03-08T02:00:00.000Z. Il report della community mostra che la stessa chiamata ha successo per intervalli immediatamente prima e dopo quel timestamp esatto, e fallisce con {"errorCode":"INTERNALSERVERERROR","message":"An internal server error occurred while performing this operation."} quando il limite include il timestamp. [1]
Cause comuni
- Un bug lato server nel parsing di data/ora o un bug di confine nella routine di ricerca che si attiva solo per quel timestamp UTC esatto. [1]
- Un caso limite di record indicizzato in cui un record o una voce di indice ha un valore corrotto o insolito esattamente a quel timestamp. [1]
- Una regola nella pipeline di ricerca (ordinamento, filtro o aggregazione) che si interrompe su quel valore limite. Il report mostra che la rimozione di sortBy o from non ha evitato l'errore. [1]
- Un comportamento di transizione dell'orologio/fuso orario a livello di piattaforma o la gestione dei secondi intercalari che produce uno stato non gestito in quell'istante. [1]
Come risolvere
- Soluzione a breve termine: evitare di chiamare modifiedTimeRange che include 2026-03-08T02:00:00.000Z. Interroga intervalli che terminano a 2026-03-08T01:59:59.999Z o iniziano a 2026-03-08T02:00:00.001Z per aggirare il limite. [1]
- Strategia di ritentativo: se devi coprire il limite, dividi la richiesta in due query (prima e dopo il timestamp esatto) e unisci i risultati lato client. Utilizza limit e paginazione per mantenere ogni query piccola. [1]
- Riproduci e acquisisci la diagnostica: esegui i tre casi di test seguenti e raccogli coppie complete di richieste e risposte (URL, stringa di query, intestazioni con Authorization mascherata, corpo della risposta e timestamp):
- Caso di successo prima del limite: modifiedTimeRange=2026-03-08T01:58:00.000Z,2026-03-08T01:59:59.000Z (previsto 204). [1]
- Caso di fallimento che raggiunge il limite: modifiedTimeRange=2026-03-08T01:59:59.000Z,2026-03-08T02:00:00.000Z (restituisce 500). [1]
- Caso di successo dopo il limite: modifiedTimeRange=2026-03-08T02:00:00.000Z,2026-03-08T02:00:01.000Z (previsto 204). [1]
- Apri un ticket di supporto Zoho Desk con: il tuo ID organizzazione, le tre richieste di riproduzione sopra, i corpi delle risposte completi, i timestamp e la chiamata API esatta (GET /api/v1/tickets/search). Chiedi al supporto di controllare i log del server per quel timestamp UTC e per eventuali errori di indice o di parsing. Il post della community documenta già il fallimento riproducibile, il che accelera le indagini. [1]
- Monitora una patch della piattaforma: una volta che il supporto conferma la causa principale, pianifica un ritorno dalla soluzione alternativa alle query normali dopo che avranno confermato la correzione.
Quando escalare
Se il limite blocca i flussi di lavoro di produzione o non puoi aggirarlo tramite