Remote Validation Error
Trace decoded form issues on the client-side remote failure channel.What this error means and what can trigger it
RemoteValidationError is the client-side representation of rejected form input. It is tagged data rather than an Error instance. The record always has _tag: "RemoteValidationError" and a numeric status; decoded issues and the original response body are optional.
SER constructs it after a remote form endpoint returns a valid result envelope whose decoded payload contains at least one form issue. By then, the envelope has passed its structural checks, the devalue string has parsed, and the resulting value matches SER's payload schema. A malformed envelope never gets this far; it follows the transport-failure path instead.
An already-tagged RemoteValidationError received through the general remote-failure codec is passed through as the same failure variant. That path does not construct a second object.
Exactly where it triggers
if (decoded.issues && decoded.issues.length > 0) {
throw create_remote_validation_error(decoded.issues, decoded, 400);
}The factory then creates the tagged record here:
export function create_remote_validation_error(
issues?: readonly FormIssue[],
body?: unknown,
status = 400,
): RemoteValidationError {
return { _tag: "RemoteValidationError", issues, body, status };
}The throw occurs inside the Promise used by the remote adapter. MakeEffectFromPromise catches the rejected Promise and turns the tagged value into the effect's error channel, where Effect.catchTag("RemoteValidationError", ...) can recover from it.
Why this is the case
FormError and RemoteValidationError live on opposite sides of the request boundary. While the handler is running, the server-side value records validation intent. The client-side value then adds transport-facing details such as the status and decoded response body, without leaking SvelteKit's server control-flow object into browser code.
The status defaults to 400 because the request was understood and its input was rejected. SER does not classify this as RemoteHttpError: the response carried the validation protocol successfully, and the issues are recoverable application data rather than an unknown HTTP failure.