Order item quantities could still be changed during processing. Quantity updates now require a pending order, enforced on the server even for direct API requests.
Expanded API tests for all non-pending statuses, spoofed client status, and rejection without side effects.
How to test
List exact commands and manual checks.
bun test apps/api/src/orders/order-quantity-assignment-3.test.ts
bun run check
bun run test
bun run build:web
Manual checks:
Login in as employer and try to change quantity on any order that is not pending, should receive and error toast
Screenshots or recordings
N/A
Risks / follow-ups
Concurrent status-change race: The server checks the order’s status before updating quantity, but these are separate database operations. If another process moves the order out of pending between them, the quantity update could still succeed. A follow-up should make the status check and update atomic.
Fractional-quantity validation: The API accepts numbers and checks range and inventory, but does not require whole numbers. A pending order could therefore accept a quantity such as 1.5. A follow-up should enforce integer quantities if items must be sold in whole units.
PR checklist
change is scoped to one ticket or one small reviewable concern
acceptance criteria were checked
code follows CONTRIBUTING.md
no unrelated refactor is mixed in
debug code and temporary logs are removed
relevant automated checks were run locally
changed behavior was manually tested when needed
known risks or follow-ups are called out
## Summary
Order item quantities could still be changed during processing. Quantity updates now require a pending order, enforced on the server even for direct API requests.
## Ticket / Assignment
- Ticket: [Assignment 3](https://git.letphil.com/derrick/ai-wave-02/issues/15)
## What changed
- Updated `canEditOrderItems` to allow only pending.
- Expanded API tests for all non-pending statuses, spoofed client status, and rejection without side effects.
## How to test
List exact commands and manual checks.
```bash
bun test apps/api/src/orders/order-quantity-assignment-3.test.ts
bun run check
bun run test
bun run build:web
```
Manual checks:
- Login in as employer and try to change quantity on any order that is not pending, should receive and error toast
## Screenshots or recordings
`N/A`
## Risks / follow-ups
- Concurrent status-change race: The server checks the order’s status before updating quantity, but these are separate database operations. If another process moves the order out of pending between them, the quantity update could still succeed. A follow-up should make the status check and update atomic.
- Fractional-quantity validation: The API accepts numbers and checks range and inventory, but does not require whole numbers. A pending order could therefore accept a quantity such as 1.5. A follow-up should enforce integer quantities if items must be sold in whole units.
## PR checklist
- [x] change is scoped to one ticket or one small reviewable concern
- [x] acceptance criteria were checked
- [x] code follows CONTRIBUTING.md
- [x] no unrelated refactor is mixed in
- [x] debug code and temporary logs are removed
- [x] relevant automated checks were run locally
- [x] changed behavior was manually tested when needed
- [x] known risks or follow-ups are called out
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
Order item quantities could still be changed during processing. Quantity updates now require a pending order, enforced on the server even for direct API requests.
Ticket / Assignment
What changed
canEditOrderItemsto allow only pending.How to test
List exact commands and manual checks.
Manual checks:
Screenshots or recordings
N/ARisks / follow-ups
Concurrent status-change race: The server checks the order’s status before updating quantity, but these are separate database operations. If another process moves the order out of pending between them, the quantity update could still succeed. A follow-up should make the status check and update atomic.
Fractional-quantity validation: The API accepts numbers and checks range and inventory, but does not require whole numbers. A pending order could therefore accept a quantity such as 1.5. A follow-up should enforce integer quantities if items must be sold in whole units.
PR checklist
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.