Skip to content

Document and test that /health* routes still traverse the full mutating-request middleware chain rather than bypassing it #143

Description

@Jagadeeshftw

📌 Description

In src/app.ts, app.get("/health", ...) and its siblings are registered after app.use(maintenanceMode(...)), app.use(apiKeyAuth(...)), app.use(rateLimiter()), app.use(idempotency()), and the audit middleware. Because those middlewares only act on MUTATING_METHODS and health checks are GETs, this is functionally safe today, but it's a subtle invariant: reordering any of that middleware stack, or adding a mutating health-check-style route later, could silently start gating health checks behind API-key/rate-limit/maintenance logic meant for the data API.

🧩 Requirements and context

  • Add integration tests asserting GET /health, /health/live, and /health/ready succeed even when API_KEY, MAINTENANCE_MODE=true, and a fully-exhausted rate-limit bucket are simultaneously active.
  • Add a code comment in src/app.ts near the health route definitions calling out the ordering dependency explicitly.
  • Add a short README/architecture note explaining why health checks are safe today and what would need to change if a mutating health-adjacent route were ever added.

🛠️ Suggested execution

  • Add tests to src/index.test.ts (or a new app.test.ts) constructing createApp() with maintenance mode and an API key configured, exhausting the rate limiter, and asserting health routes still return 200.
  • Add the explanatory comment to src/app.ts.
  • Add the README/docs note.

✅ Acceptance criteria

  • New tests demonstrate health routes are unaffected by maintenance mode, API-key enforcement, and rate limiting simultaneously.
  • app.ts and README/docs clearly explain the middleware-ordering invariant this relies on.

🔒 Security notes

Documents and locks in via tests an invariant that, if silently broken by a future change, could either wrongly block health checks (causing false-negative liveness/readiness signals) or wrongly bypass security middleware for a future route registered in the same spot.

📋 Guidelines

  • Minimum 95% test coverage
  • Clear documentation
  • Timeframe: 96 hours

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions