Replit Agent prompt to add error handling
Generated apps usually handle the happy path and crash on everything else. This prompt walks Replit Agent through your existing Repl and retrofits an error strategy at three levels, server responses, client screens, and process restarts, then makes it prove the work by deliberately breaking the database connection and a form submission.
Last updated
Audit the app in this Repl and retrofit error handling at every layer. Do not change the shape of successful responses.
Server: wrap route handlers so thrown errors become a JSON envelope { "error": { "code", "message", "requestId" } }, with the stack logged server-side and never sent to the client. Distinguish operational failures (validation, not found, upstream timeout) from bugs, and map each to a correct status code. Outbound HTTP calls get a timeout and one retry with backoff. If the database is unreachable at startup, retry the connection with a delay instead of crashing.
Client: add a fetch wrapper that converts non-2xx responses into typed errors. Every screen that loads data needs a visible failure state with a retry action, no blank sections, no infinite spinners. Form submissions display the server's per-field validation messages next to the inputs.
Process: install handlers for unhandledRejection and uncaughtException that log and exit cleanly so the Replit runtime restarts the app.
Prove it, do not just claim it: temporarily set the database URL to a wrong value and show what users see, then restore it. Submit a form with invalid data and screenshot the field messages. Point one outbound call at an unreachable host and show the timeout path. When finished, paste the final error envelope shape, give a route-by-route rundown of the failure handling each endpoint gained, and justify any dependency you added in one line. Prefer zero new dependencies.Same task in other tools
Questions about this prompt
Will this change how my working endpoints behave?
Successful responses keep their shape; the prompt only standardizes failures. Do scan the diff for handlers that previously returned plain-text errors, because any client parsing those strings will need updating for the JSON envelope.
How do I know the agent actually tested the failure paths?
The prompt has it break things deliberately: a wrong database URL, an invalid form submission, an unreachable outbound host, each restored afterward. If the reply just says verified, ask for the screenshots and the exact responses from each experiment.
The agent suggests adding an error tracking service. Should I?
Skip it during this pass. The envelope and the process handlers give you one choke point for every failure, so a tracking SDK becomes a small follow-up once the retrofit is stable. Folding a vendor signup into an error-handling audit just gives the agent two jobs to stall on.