Si algo falla

Hay dos tipos de “fallo”. Uno es el dato malo (va en issues). El otro es que la librería no pudo trabajar (una excepción).

Si la IA no contesta

El provider puede caerse, tardar demasiado o devolver basura. EDcheck no tira toda la request. Crea un issue semantic_unavailable por cada regla que quedó viva.

• open (el default): esos issues son warning. success no cambia por esto.
• closed: esos issues son error. El parse queda en success: false.

const edcheck = createEDcheck({  provider,  policy: "closed",  timeoutMs: 8000,});

timeoutMs por defecto es 10000 (10 segundos). Si se acaba el tiempo, cuenta como fallo del provider, no como cancelación.

También puedes poner policy en un define concreto. Ese schema gana sobre la instancia.

Cancelar un parse

Pasa un signal. Si se aborta, safeParse lanza EDcheckAbortError. No te devuelve un result.

const controller = new AbortController(); try {  const result = await UserSemantic.safeParse(input, {    signal: controller.signal,    timeoutMs: 5000,  });} catch (error) {  if (error instanceof EDcheckAbortError) {    // el usuario se fue, o tú llamaste controller.abort()  }}

Los errores que puedes atrapar

Todos heredan de EDcheckError y traen un code string. EDcheckConfigError a veces trae path. EDcheckProviderError trae retryable y a veces status.

En un parse normal, el fallo del provider casi nunca te llega como excepción: se vuelve semantic_unavailable. La excepción aparece si cancelas, si configuraste mal, o si estás en el navegador.