This is a comment left during a code review.
Path: src/slack/monitor/provider.ts
Line: 236

Comment:
**`readRequestBody` bypasses all size and timeout guards**

`readRequestBody(req)` buffers the entire network body into memory with no byte-size limit and no timeout. The `SLACK_WEBHOOK_MAX_BODY_BYTES` (1 MB) and `SLACK_WEBHOOK_BODY_TIMEOUT_MS` (30 s) protections are only applied to the `PassThrough` replay on `mockReq`, which already holds the pre-buffered data by the time `installRequestBodyLimitGuard` runs. This means:

1. **Memory exhaustion**: An attacker can send an arbitrarily large body that is fully buffered before any size check occurs. The guard will eventually trip and send a 413, but the damage (heap spike) has already happened.
2. **Timeout bypass**: A slow/stalling client can hold the HTTP connection open indefinitely during `readRequestBody`. The 30 s timeout on `mockReq` fires almost immediately (the PassThrough stream drains instantly), so it offers no protection against sluggish senders.

The pre-read is necessary to inspect the `type` field before Bolt's signature verification runs. The fix is to apply the limit guard *during* the initial body read instead of re-applying it to the replay stream:

```typescript
// Read with the same limits as the guard, then decide what to do
let rawBody: string;
try {
  rawBody = await readRequestBodyWithLimit(req, {
    maxBytes: SLACK_WEBHOOK_MAX_BODY_BYTES,
    timeoutMs: SLACK_WEBHOOK_BODY_TIMEOUT_MS,
  });
} catch (err) {
  if (isRequestBodyLimitError(err)) {
    // send the appropriate 4xx and return
    ...
  }
  throw err;
}
```

(Both `readRequestBodyWithLimit` and `isRequestBodyLimitError` are already exported from `../../infra/http-body.js`.)

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/slack/monitor/provider.ts
Line: 258-268

Comment:
**Incomplete stream proxy may silently break with Bolt upgrades**

`mockReq` overrides `on`, `read`, `removeListener`, and `emit` to delegate to `passThrough`, but all other `Readable`/`IncomingMessage` stream properties and methods still resolve via prototype to the original, already-consumed `req`. Notably:

- **`mockReq.readableEnded`** (a getter that reads `this._readableState.endEmitted`) will return `true` because `req._readableState.endEmitted` is `true` after `readRequestBody` drained the socket. If `@slack/bolt`'s `HTTPReceiver` or a middleware (e.g., `raw-body`) checks `req.readableEnded` before attaching a `'data'` listener, it may treat the body as already consumed and skip reading — even though `passThrough` still has the buffered data.
- `readable`, `readableLength`, `readableHighWaterMark`, `_readableState`, `resume()`, `pause()`, and `destroy()` all inherit from `req`, not from `passThrough`.

A safer approach is to construct `mockReq` from `passThrough` directly and copy only the HTTP-level properties from `req`, or use an explicit wrapper class. This avoids cross-stream property leakage and makes the proxy contract explicit.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/infra/json-files.ts
Line: 80

Comment:
**Unreachable `throw lastError` after retry loop**

The `for` loop always exits via either `return` (on success) or `throw err` (inside the `catch` block, on non-retryable errors or the final attempt). It never exhausts the iteration counter without throwing, so this `throw lastError` is dead code. Additionally, `lastError` is typed as `Error | undefined`, so if this line were somehow reached it would throw `undefined`.

Consider removing the trailing `throw` or replacing the loop with a pattern that makes the termination condition more explicit:

```suggestion
  }
  // loop always returns or throws above; this line is unreachable
```

How can I resolve this? If you propose a fix, please make it concise.