If something fails
What happens if the AI does not answer, if you cancel, or if EDcheck is misconfigured.
There are two kinds of “failure”. One is bad data (it goes into issues). The other is that the library could not work (an exception).
If the AI does not answer
The provider can go down, take too long, or return junk. EDcheck does not throw away the whole request. It creates a semantic_unavailable issue for each rule that was still alive.
open(the default): those issues arewarning.successdoes not change because of this.closed: those issues areerror. The parse ends withsuccess: false.
const edcheck = createEDcheck({ provider, policy: "closed", timeoutMs: 8000,});timeoutMs defaults to 10000 (10 seconds). If time runs out, it counts as a provider failure, not as a cancellation.
You can also set policy on a specific define. That schema wins over the instance.
Cancel a parse
Pass a signal. If it aborts, safeParse throws EDcheckAbortError. You do not get a result.
const controller = new AbortController(); try { const result = await UserSemantic.safeParse(input, { signal: controller.signal, timeoutMs: 5000, });} catch (error) { if (error instanceof EDcheckAbortError) { // the user left, or you called controller.abort() }}Timeout ≠ cancel. A timeout is treated as “the AI did not answer” and follows the open/closed policy. Cancel throws.
Errors you can catch
| Error | When it appears |
|---|---|
EDcheckEnvironmentError | You called EDcheck in the browser. |
EDcheckConfigError | Bad setup: missing provider, unknown path, duplicate id… |
EDcheckAbortError | You cancelled the parse. |
EDcheckProviderError | The provider failed internally (HTTP, network, timeout, bad response). |
They all extend EDcheckError and carry a string code. EDcheckConfigError sometimes has path. EDcheckProviderError has retryable and sometimes status.
On a normal parse, a provider failure almost never reaches you as an exception: it becomes semantic_unavailable. The exception shows up if you cancel, if setup is wrong, or if you are in the browser.