feat: complete LP5 operations and capacity proof - #8
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 83031bed05
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const abuseDecision = runtime.rateLimiter.consume({ | ||
| channel: abuseChannel, | ||
| tenantId: session?.tenantId ?? 'anonymous', | ||
| ipAddress: request.socket.remoteAddress ?? 'unknown', |
There was a problem hiding this comment.
Resolve client IP before applying the shared limiter
When the runtime is deployed behind the documented edge/reverse proxy, request.socket.remoteAddress is the proxy address rather than the originating client. Consequently, every client shares the same IP bucket—only 120 HTTP/API requests per minute by default—so normal aggregate traffic can cause installation-wide 429 responses. Use a client identity supplied through explicitly trusted proxy configuration, or enforce the client-IP limit at the edge instead.
Useful? React with 👍 / 👎.
| const abuseChannel = abuseChannelForPath(path); | ||
| const abuseDecision = runtime.rateLimiter.consume({ | ||
| channel: abuseChannel, | ||
| tenantId: session?.tenantId ?? 'anonymous', | ||
| ipAddress: request.socket.remoteAddress ?? 'unknown', | ||
| }); |
There was a problem hiding this comment.
Exempt operational probes from user traffic limits
Because the limiter runs before route dispatch, /health/live, /health/ready, and /metrics return 429 after their source IP consumes 120 HTTP requests in the minute (or after the shared anonymous tenant bucket is exhausted). In environments where probes or scrapes share an address with application traffic, a healthy process can therefore be marked unhealthy and its metrics become unavailable; operational endpoints should bypass user-facing limits or use independent probe limits.
Useful? React with 👍 / 👎.
| const response = await fetch(`${baseUrl}${path}`, { redirect: 'manual' }); | ||
| if (response.status >= 500) throw new Error(`${path} returned ${response.status}`); |
There was a problem hiding this comment.
Reject unexpected statuses in capacity probes
The LP5 capacity gate treats every response below 500 as a successful timing sample, so a missing web route returning 404, an unauthorized endpoint returning 401, or a rate-limited probe returning 429 contributes zero HTTP errors and can still produce a passing report. Validate the expected status for each probe—200 for / and the configured DAV redirect status—so functional failures cannot be recorded as successful capacity evidence.
Useful? React with 👍 / 👎.
Completes the LP5 local security, abuse, observability, patch-state, and bounded-capacity proof. Records AMD64-first and final ARM64 artifact evidence, updates canonical memory/deployment/milestone documents, README status, and the LP5 release manifest. Local npm test and LP5 gates passed; AMD64 run 32870823846 and final ARM64 artifact/attestation run 32866904673 are green. Production capacity and external interoperability remain out of scope.