Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

The join endpoint returns an error shape the frontend cannot read

Open Beginner friendly
  • Is something wrong?
#192 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
86/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
express, react, typescript
Domain
api, backend, frontend

Research direction

Read apps/http-server/src/controllers/sessionController.ts and the shared apps/http-server/src/utils/error.ts helper, then search the service for raw res.status(...).json({ message }) calls on error paths. Replace the join endpoint response with the shared helper and check that the join screen reads the server message. Done when all http-server errors use { success: false, error: string } and no raw message-shaped error responses remain.

Written by the indexing model from the issue text.

Description

Backend first issue bug good first issue help wanted

Every error in http-server goes through a shared helper:

// apps/http-server/src/utils/error.ts
export const errorResponse = (res: Response, statusCode: number, message: string) => {
    return res.status(statusCode).json({ success: false, error: message })
}

One line does not:

// apps/http-server/src/controllers/sessionController.ts:15
if (!code || !username) {
    return res.status(400).json({ message: "Code and username are required" });
}

Confirmed against the live API:

POST /api/v1/session/join  {}
→ {"message":"Code and username are required"}      # every other endpoint sends {success, error}
Why it matters

It is not only inconsistent — the message is silently dropped. The join screen reads .error:

// apps/frontend/src/screens/JoinQuiz.tsx
type JoinRequestError = { response?: { data?: { error?: string } } };
...
setError(joinError.response?.data?.error || "Failed to join quiz");

The server sends .message, so the fallback always wins and the user sees the generic "Failed to join quiz" instead of what actually went wrong.

The join screen validates client-side first, so today this mostly affects direct API calls and anything that bypasses the form — but it is a real swallowed message, and the inconsistency is a trap for the next person who adds an endpoint here.

What a fix looks like
return errorResponse(res, 400, "Code and username are required");

Then check the rest of the service for other raw res.json calls on error paths. The convention is well established — errorResponse is used 22 times in quizController, 9 in authController, 7 in inviteController, 5 elsewhere in sessionController — so anything else that does not use it is probably the same oversight.

Definition of done
  • Every error response from http-server has the shape { success: false, error: string }
  • The join screen shows the server's message rather than its fallback
  • No other raw res.status(...).json({ message }) remains on an error path

Good first issue: one line to fix, and a good way to learn a codebase convention by finding where it was not followed.

Dominant language
TypeScript
Stars
21
Forks
7
Avg merge
3h 39m
Merged PRs (30d)
16

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 TheCodeHeist-Coder/Rexial

All issues in TheCodeHeist-Coder/Rexial

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.