📌 Description
cmd/api/main.go wires up the Fiber app, DB pool, bus, and background workers, then waits on OS signals to shut down. There is no test verifying the shutdown sequence actually closes dependencies in a safe order (HTTP listener first, then bus, then DB) so a regression here could silently drop in-flight requests or leak connections.
🧩 Requirements and context
- Extract the shutdown sequence into a small testable function if not already isolated.
- Assert that new HTTP connections are rejected before the DB pool is closed.
- Assert bus consumers are drained/unsubscribed before the process exits.
- Document the intended shutdown order in a comment above the sequence.
Non-functional requirements
- Must be secure, tested, and documented.
- Should be efficient and easy to review.
🛠️ Suggested execution
1. Fork the repo and create a branch
git checkout -b test/api-shutdown-ordering
2. Implement changes
- Modify:
cmd/api/main.go — isolate the shutdown sequence behind a function that accepts the dependencies as parameters so it can be unit tested without a real network listener.
- Add test: a new
cmd/api/main_test.go exercising the shutdown order with fake/mock dependencies.
3. Test and commit
- Cover edge cases: signal received mid-request, signal received twice, dependency close returning an error.
- Include test output and details in the PR description.
Example commit message
test: verify graceful shutdown ordering in cmd/api/main.go
✅ Acceptance criteria
🔒 Security notes
Threat: an out-of-order shutdown could close the DB pool while requests are still being handled, causing panics or corrupted responses. Validate the fix doesn't mask errors returned by individual close calls.
📋 Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
📌 Description
cmd/api/main.gowires up the Fiber app, DB pool, bus, and background workers, then waits on OS signals to shut down. There is no test verifying the shutdown sequence actually closes dependencies in a safe order (HTTP listener first, then bus, then DB) so a regression here could silently drop in-flight requests or leak connections.🧩 Requirements and context
Non-functional requirements
🛠️ Suggested execution
1. Fork the repo and create a branch
2. Implement changes
cmd/api/main.go— isolate the shutdown sequence behind a function that accepts the dependencies as parameters so it can be unit tested without a real network listener.cmd/api/main_test.goexercising the shutdown order with fake/mock dependencies.3. Test and commit
go test ./cmd/api/... -vExample commit message
✅ Acceptance criteria
internal/shutdown/wait.gotimeout behavior still applies.🔒 Security notes
Threat: an out-of-order shutdown could close the DB pool while requests are still being handled, causing panics or corrupted responses. Validate the fix doesn't mask errors returned by individual close calls.
📋 Guidelines