Nobody has started this yet — be first.
Business impact
This is the kind of bug a user discovers mid-dinner-party. Someone doubles a recipe from 4 servings to 8 expecting twice the ingredients, and instead gets half -- 250g of chicken instead of 1000g. If they trust the app and don't sanity-check the numbers, they end up under-provisioned for guests, or (scaling down) drowning a 2-person meal in 4x the ingredients. It erodes trust in the one feature (scale) whose entire value proposition is "do the arithmetic correctly so the user doesn't have to." The README's own curl walkthrough documents the correct output (500g -> 1000g for 4 -> 8 servings) -- the running code no longer matches its own docs.
Problem
PATCH /recipes/:id/scale with { "targetServings": 8 } on a recipe with servings: 4 returns ingredient quantities divided by 2 instead of multiplied by 2.
Current behavior
Scaling a recipe from 4 servings to 8 returns 250g of chicken instead of 1000g, and scaling from 4 down to 2 returns 1000g instead of 250g -- the result moves the opposite direction from what was requested.
Expected behavior
Scaling from servings: S to targetServings: T should multiply every ingredient quantity by T / S. Scaling up (T > S) increases quantities; scaling down (T < S) decreases them.
Steps to reproduce
curl -X POST http://localhost:3001/recipes -H "Content-Type: application/json" -d '{ "title": "Test Recipe", "cookingTimeMinutes": 20, "servings": 4, "ingredients": [{"name": "Chicken breast", "quantity": 500, "unit": "g"}], "steps": [{"stepNumber": 1, "instruction": "Cook it."}] }'
curl -X PATCH http://localhost:3001/recipes/<id>/scale -H "Content-Type: application/json" -d '{"targetServings": 8}'
Why this matters
This is a classic "operands swapped" arithmetic bug: the ratio is computed as recipe.servings / targetServings instead of targetServings / recipe.servings. Both expressions type-check, both produce a plausible-looking number, and unless you check the direction of the result (bigger target -> bigger quantities) the bug is invisible from reading the code casually -- you have to actually work through which operand should be on top.
Suggested approach
Find the ratio calculation in the scale handler in src/routes/recipes.js. Think through the ratio from first principles: if targetServings is larger than recipe.servings, the ratio must be greater than 1 (quantities grow); if smaller, less than 1 (quantities shrink). Check which of recipe.servings and targetServings needs to be the numerator for that to hold.
Acceptance criteria
Verification
npx jest --config practice-tickets/jest.config.js practice-tickets/tests/02-scale-ratio-inverted.test.js
Hints (0/2)
Try it without hints first — the reading is the exercise.
Working on this ticket
Work on a branch named for the ticket — that's what you'll submit.
Branch off your fork
$git checkout -b fix/scale-ratio-invertedFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin fix/scale-ratio-invertedSubmit it below
Paste your fork URL and the branch name, with a short write-up of the root cause.
Questions
Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.
Sign in to ask a question or reply.
Sign indocker-entrypoint.shnpx prisma migrate deploydocker compose up --builddocker compose down -vWithout Docker: npm install, copy .env.example to .env and point DATABASE_URL at a local PostgreSQL instance, then npm run prisma:migrate:dev and npm run dev (nodemon, port 3001) or npm start.
The project's own suite (tests/recipes.test.js) runs against a real Postgres test database, not a mock -- create one, copy .env.example to .env.test and point it at that database, then run:
npm test
Work the tickets in practice-tickets/tickets/ (01 through 07); each names one Jest test in practice-tickets/tests/, run against the same real test database via practice-tickets/jest.config.js:
npx jest --config practice-tickets/jest.config.js practice-tickets/tests/01-max-cooking-time-boundary.test.js # a single ticket
./practice-tickets/run.sh # all 7, clean pass/fail summary
Fixing tickets 02 and 04 also turns two tests in the project's own npm test suite green again -- they break as a direct, expected side effect of those bugs touching shared route code the existing suite also exercises. That's expected, not a mistake in the scaffolding.
Level 1
Fix a bug
Read existing behaviour, correct it.