Respuestas
Si cada sesión tiene que leer de un servicio antes de actuar, ¿qué pasa cuando ese servicio tiene un mal segundo?
La lectura se intenta de nuevo en lugar de fallar. Una base de datos que escala a cero rechaza la primera llamada tras un período inactivo mientras su cómputo despierta, y lo dice: el rechazo trae una marca explícita del proveedor que significa que la llamada nunca llegó a un cómputo y puede repetirse. Esa marca antes se ignoraba aquí, y el rechazo viajaba entero hasta quien llamó como lectura fallida — lo que, para una sesión cuyo primer acto es revisar qué decidió ya el equipo, significa seguir sin eso. Desde septiembre de 2026 un rechazo con esa marca se reintenta, hasta tres intentos, con un costo del orden de tres cuartos de segundo en el peor caso. Dos límites impiden que esto sea una licencia: solo cuenta la declaración del propio proveedor, nunca nuestra lectura de un mensaje de error, y solo se repite lo que es inequívocamente una lectura. Todo lo que escribe se intenta exactamente una vez, como antes.
Última actualización 22 de septiembre de 2026
Una comprobación que puede fallar es una comprobación que la gente deja de hacer
Leer antes de actuar solo sobrevive si leer es confiable. La primera vez que la lectura de apertura da error en medio del trabajo, el trabajo sigue sin ella, porque el trabajo es lo que alguien está esperando. La segunda vez, alguien la envuelve y sigue. Para la tercera es adorno: sigue en el código, sigue en la descripción de la rutina, y ya no sostiene nada. El costo de una comprobación poco confiable nunca es la llamada que falló — es que la regla deja de ser regla en silencio, y nada anuncia el día en que eso pasó.
Quien dice que la llamada puede repetirse es el proveedor; nosotros no adivinamos
La decisión de reintentar no es nuestra para inferirla. Una base que duerme cuando está inactiva responde la primera llamada tras el silencio con un rechazo que se declara repetible, porque la llamada nunca llegó a un cómputo en pie. Esa marca es lo que se lee — nunca la prosa del mensaje, que está escrita para personas y se reescribe sin aviso. Un rechazo que no declara nada sigue siendo final: el silencio del proveedor no es permiso. Esa dirección importa más de lo que parece, porque repetir algo que el proveedor no marcó es adivinar que una operación no surtió efecto, y ese es el tipo de conjetura que algún día aplica algo dos veces.
Las lecturas se repiten; las escrituras se intentan una vez
El segundo límite es la instrucción misma, y la prueba falla cerrada: lo que no se reconoce con certeza como lectura pura no se repite. La asimetría es la razón entera de que esto sea seguro. Confundir una lectura con una escritura cuesta exactamente el comportamiento viejo — la llamada no se reintenta y nadie queda peor que antes. Confundir una escritura con una lectura cuesta una escritura aplicada dos veces. Por eso la prueba es deliberadamente estrecha y deliberadamente desconfiada: una instrucción que abre como lectura pero carga una escritura en cualquier punto se trata como escritura. Y el reintento tiene techo — tres intentos, esperas cortas, del orden de tres cuartos de segundo en el peor caso — porque una lectura que se cuelga es peor que una que falla, ya que nada del lado de quien llamó la distingue de una lectura que está funcionando.
Cómo se ve en la práctica
Una rutina programada abre a las tres de la mañana. Es lo primero que toca el proyecto en varias horas, así que el cómputo de la base está dormido, y despertarlo toma una fracción de segundo. Su primera instrucción es la lectura de apertura: qué decidió este equipo, qué está en curso, qué dejó la noche anterior. Esa es la llamada que se encuentra al cómputo subiendo, y es rechazada — con la marca del proveedor diciendo que la llamada nunca llegó y puede repetirse. Con el comportamiento viejo, eso aparecía como error. La rutina no se detenía, porque una rutina que se detiene con la base fría es una rutina que se detiene casi todas las noches. Seguía y hacía el trabajo: abría archivos, cambiaba cosas, escribía su resultado. Lo que no hacía era leer las reglas, y nada en su salida lo decía. La parte cara no es la llamada que falló — es la hora de trabajo construida encima de ella. Hoy el mismo rechazo cuesta una espera medida en cientos de milisegundos, el segundo intento encuentra un cómputo en pie, y la lectura llega. La rutina nunca se entera de que pasó algo, y ese es el desenlace correcto: un cómputo despertando es infraestructura, no noticia.
Preguntas que la gente hace sobre esto
- ¿Reintentar no está tapando una caída real?
- Tapa exactamente los rechazos que se declaran temporales, y nada más. Una caída real no produce esa declaración — produce una conexión que no responde, o un error sin marca alguna — y ahí los intentos se agotan y la lectura falla a la vista, informando cuántos fueron. La línea entre las dos la traza el proveedor en su propia respuesta, no nosotros leyendo el poso del café en un texto de error, y eso es lo que impide que el reintento se convierta en una manera de no enterarse.
- ¿Cuánto puede quedarse esperando quien llamó?
- Tres intentos, con esperas cortas entre ellos, que suman del orden de tres cuartos de segundo en el peor caso antes de que la falla aparezca. El techo es pequeño a propósito. Esperar más cambiaría una falla visible por una invisible: quien llamó no distingue una lectura lenta de una lectura que funciona, y una sesión colgada mientras revisa las reglas es peor para todos que una sesión a la que le avisan que la revisión falló.
- Preferimos que nuestro agente falle duro antes que actuar con algo incompleto. ¿Esto cambia lo que recibe?
- No. Un reintento devuelve la misma lectura que habría devuelto el primer intento; nada se descarta, se resume ni se rellena para que la llamada salga bien. Y la falla de la que te estás protegiendo es justo la que producía el comportamiento viejo: un agente que preguntó qué había decidido el equipo, escuchó que la base estaba ocupada, y siguió igual. Si la lectura de verdad no puede entregarse, sigue fallando — y falla lo bastante fuerte como para quedar registrada en vez de absorbida.
Dónde se puede comprobar
Documentación de producto en este sitio (Cómo funciona, Instalación), las respuestas sobre lecturas que dejan de costar lo mismo cuando nada cambió y sobre rutinas de IA programadas que pierden el hilo, y las reglas de reintento, clasificación de lectura pura y seguridad de escritura en la especificación sancionada del producto. El comportamiento descrito aquí llegó a producción el 12 de septiembre de 2026. Todo lo descrito aquí es comportamiento que las herramientas aplican hoy, no roadmap.
https://www.arroway.app/es/answers/reads-that-recover-from-a-retryable-database-error