Skip to content

Error Handling

Type(error: UpdogError) => void

Called when the SDK catches an internal error. The SDK recovers gracefully where possible — onError is for your logging and monitoring (Sentry, Datadog, etc.).

type UpdogError = {
code: UpdogErrorCode;
message: string;
source: string;
originalError?: unknown;
};
CodeWhen
PARSE_ERRORFile parsing failed (corrupt CSV, invalid XLSX, etc.)
RENDER_ERRORComponent render failed (caught by error boundary)
TRANSFORM_ERRORData transformation failed (column transform, value mapping)
VALIDATION_ERRORValidation execution failed (validator threw instead of returning)
WORKER_ERRORWeb Worker failed (filter worker, chat transform worker)
COMMAND_ERRORUndo/redo command failed
OPERATION_ERRORGeneral operation failed (bulk mutations, imports)
onError={(error) => {
Sentry.captureException(error.originalError ?? error, {
tags: { code: error.code, source: error.source },
});
}}

Remote checks (unique.fn and { type: "asyncFunction" } validators) can fail in ways sync validation cannot. When a check throws, returns malformed data, or goes 60 seconds without any activity, the cells still awaiting a verdict become unverified: they are not marked invalid, and your backend should re-validate them at save time.

  • A check failure (rejection or malformed result) is reported through onError as a VALIDATION_ERROR — once per sweep, not once per cell. A timeout is silent.
  • Verdicts streamed via onChunk before a failure stay applied — a crash at 99% keeps the 99%.
  • Do retries inside your fn; once it rejects, the SDK marks the remaining cells unverified and does not re-ask.

Malformed rows in a CSV (for example, an unclosed quote) don’t fail the import. The file still parses and the rows enter the grid; the user sees a toast reporting how many rows had formatting issues and the first few affected row numbers. These warnings are informational and are not reported through onError. A hard parse failure still raises a PARSE_ERROR.