Return 400/404 instead of 500 for bad requests to the local API

Open
  • Is something wrong?
#2 0 comments 0 reactions 0 assignees View on GitHub

@jay23606 is already working on this.

Since Nov 7, 2026.

  • #20 by @jay23606 — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
javascript, node.js
Domain
api, backend, testing

Research direction

Start with the error handling in server/index.mjs and the named functions in server/library.mjs and server/director.mjs; then inspect scripts/check.mjs for how API cases are exercised. Add the requested status handling, safe filename decoding, and JSON parse error message, and verify the listed responses and console output with npm run check. An open linked pull request (#20) is already working on this issue.

Written by the indexing model from the issue text.

Description

bug good first issue

The server's catch-all maps any error without a status to HTTP 500 and prints a stack trace to the console. Several ordinary user mistakes take that path. Each of these was run against a fresh server:

Request Got Should be
GET /api/projects/nope 500 ENOENT: no such file or directory, open '…/projects/nope.json' 404
DELETE /api/library/nope 500 ENOENT …/images/nope.json 404
POST /api/direct with {"prompt":""} 500 Write an idea first 400
POST /api/direct with {"director":"bogus"} 500 Unknown director bogus 400
POST /api/upload with header x-file-name: 100%.png 500 URI malformed 400, or fall back to a default name

The reverse problem also exists. When a director model returns broken JSON, parseJson() re-throws the SyntaxError from its second JSON.parse. The handler maps every SyntaxError to 400, so the model's fault comes back as a client error with a message like "Unexpected token…".

Task:

  • give these errors a status (the codebase already uses Object.assign(new Error(...), { status }))
  • map ENOENT from loadProject and deleteImage to 404
  • make decodeURIComponent of x-file-name safe
  • wrap the second JSON.parse in parseJson so it throws "The director did not return JSON"
  • add steps to scripts/check.mjs for the 404 and 400 cases

Where: server/index.mjs:116, server/index.mjs:118, server/index.mjs:138-141, server/index.mjs:146-150; server/library.mjs:49-54 (deleteImage), server/library.mjs:66-68 (loadProject); server/director.mjs:60, server/director.mjs:67-68, server/director.mjs:78; scripts/check.mjs.

Done when: npm run check passes with new steps asserting 404 for GET /api/projects/nope and DELETE /api/library/nope, 400 for POST /api/direct with {"prompt":""} and with {"director":"bogus"}, and a non-500 answer for POST /api/upload with x-file-name: 100%.png, with no stack trace in the server console; a director reply that isn't JSON surfaces as "The director did not return JSON", not a 400 Unexpected token….

Getting started: Node 22, no npm install needed: git clone, then npm test and npm run check. Comment here to claim it. Questions → Discord.

Dominant language
JavaScript
Stars
42
Forks
6
Avg merge
12h 31m
Merged PRs (30d)
3

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from blixvip/GenMotion

All issues in blixvip/GenMotion

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.