Skip to main content
Most errors in EdgeSpark have a clear cause and a clear fix. This page explains what each error means and how to resolve it without stopping for human input.

Type errors

Symptom: edgespark deploy or tsc fails during type checking. Cause: Code references a table, bucket, var, secret, or runtime import that does not match the repo-owned defs or generated SDK types. Fix:
If the problem is schema-related, confirm that server/src/defs/db_schema.ts, server/src/defs/storage_schema.ts, and server/src/defs/runtime.ts match the code you wrote.

Migration errors

Symptom: Schema changes are not reflected in the database or deploy fails around migrations. Fix:
If destructive SQL is intentional, rerun with:

Build errors

Symptom: edgespark deploy fails at the build step.

Missing default app export

Fix: Ensure server/src/index.ts exports a default Hono app:
server/src/index.ts

Route outside /api/*

If deploy reports a route outside /api/*, move it under /api/*, /api/public/*, or /api/webhooks/*.

Bundle too large

Check for large dependencies or large static assets. See platform limits.

SQL validation rejections

Symptom: A request fails at runtime after a successful deploy. Common cases: Check the exact rejection with:

Runtime null errors

Symptom: A handler throws because a row or file does not exist. Fix:

Stale type warnings

Symptom: The CLI says local SDK types are stale. Fix:
To check without writing files:

When to stop and ask for human input

Stop and ask when:
  • You need the user to complete edgespark login
  • You need the user to set a secret value through the secure secret-entry flow
  • The next fix is destructive, such as dropping schema or deleting existing data

See also

Declarative workflow

How defs, migrations, pulled schema, and generated types fit together.

Minimal human input

Which situations require stopping instead of fixing autonomously.
Last modified on April 7, 2026