AI Study Backend

Overview

AI Study Backend is the backend service for the AI Study Companion platform, an open-source project under open-source-collabs. The platform owns the study workflow (users, study materials, generated artifacts, sessions and progress) and treats AI providers as replaceable integrations behind one interface, rather than acting as a chat proxy.

I joined while the repository foundation was being laid and contributed the configuration and error-handling layers every later feature will sit on. Five pull requests, all merged.

What I built

• Application configuration: a single configuration boundary under src/config that resolves the environment once at startup and exports a frozen config object, so no other module reads process.env directly.
• Safer startup values: PORT is validated as a real TCP port (an integer from 1 to 65535) and falls back to 3000 with a warning. Before, PORT=99999 crashed startup and PORT=4100abc was silently accepted. NODE_ENV is trimmed and defaults to development.
• Error architecture: completed the HTTP status enum (adding 422) and added ValidationError, AuthenticationError, AuthorizationError, NotFoundError and ConflictError on top of the AppError base, each taking its status code from the enum.
• Centralized environment loading: moved dotenv loading from Express startup into the configuration module, so tools that never boot the server (sequelize-cli migrations and seeders) still see the environment.
• Async error handling: hardened the global error handler and documented the async handler contract for Express 5.

Bugs found and fixed

Testing the existing global error handler against the real middleware turned up genuine defects, which these changes fix:

• A malformed status code escaped the handler. An error carrying a non-integer or out-of-range statusCode made response.status throw, and Express fell back to its default HTML error page, which exposed a full stack trace and absolute file paths. The handler now validates the status and reports anything unusable as an unexpected 500.
• A response could be written twice. When a handler failed after already responding, the error handler tried to respond again and threw ERR_HTTP_HEADERS_SENT. It now hands the error to next() in that case.

Verification

The middleware was exercised directly rather than through an invented feature: 23 assertions in development and 37 in production, covering 401, 403, 404, 409 and 422 responses, custom statuses, native errors, malformed statuses, unknown routes and async rejections. In production, responses were checked to contain no stack trace and no file paths.

What comes next

The repository foundation and database architecture are in place; study features, domain models and tables come next, and will use this configuration and error layer from day one.