Repository navigation
fix(host-cloudflare): una caída breve de D1 ya no hace fallar search ni invoke - #41
Merged
Merged
Conversation
Author
|
El CI de Blacksmith no corre en este repositorio (todas sus ejecuciones quedan en cola o canceladas), así que se verificó en local sobre el head 9c14439 (al día con
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Qué cambia
Cuando D1 falla por unos 15 segundos,
searcheinvokede Executor ya no devuelvenInternal tool error [id]: las lecturas se reintentan hasta 20 segundos (antes, cinco intentos en menos de 4 segundos).Causa (confirmada con logs de producción)
El 2026-10-28 entre 14:50:10Z y 14:50:26Z, D1 respondió
D1_ERROR: internal error; reference = ...a casi todas las consultas del workerexecutor-cloudflare: 86 spansd1_all/d1_runcon error y ninguna consulta exitosa entre 14:50:09 y 14:50:27. Eso explica las tres fallas de una misma ejecución de Skywardin (search14,5 s,invoke19,4 s,search3,4 s).searchno llama a ningún upstream: lee el catálogo desde D1.El reintento de D1 ya existía y se activó (avisos
D1 transient failure, retryingdesde 14:50:13). Pero la mayoría de los intentos fallidos vuelven en milisegundos, así que los cinco intentos con espera de 200 ms a 1,6 s se agotaban en menos de 4 segundos, mucho antes de que D1 se recuperara. Las tres fallas sí dejaron su línea[executor:mcp] execute defect correlation_id=...(ef70a6b1, ce1cc2d7, de660f2d); la lectura anterior de que solo una la dejaba era un error de la consulta de logs.No es un timeout upstream: la hipótesis de 19 s igual a timeout queda descartada.
Cómo se probó
vitest run src/dbenapps/host-cloudflare: 58 pruebas pasan.Cómo comprobarlo después del despliegue
Servicio
executor-cloudflare, ventana de 7 días, sin cambios en la métrica base:needle: "execute defect": línea base 3 (todas el 2026-10-28 14:50Z). Debe seguir en 0 ante un cuarto de hora de errores de D1.spanName ~ ^d1_conlevel = error: línea base 25 a 138 por día (se reintentan y se recuperan solos). Esperable que no baje; lo importante es que no aparezcan defectos.needle: "D1 transient failure": si apareced1.attemptmayor que 5 y luego la consulta tiene éxito, el presupuesto nuevo está actuando.