docs(tasks): decompose review-002 into 24 tasks (23 implementation + 1 bracketed follow-up)
Decomposition of docs/reviews/002-post-remediation-review.md per its 5-unit remediation plan: - Unit 1 (security-critical): gw15-publish-body-cap, prj16-schema-via-call (CF-004 filed alkcall-side), fwd13-dot-segments, fwd16-missing-capability, oai11-ref-memoization - Unit 2 (timeout/terminality): ws13-idle-progress, fwd15-stream-timeout, cli01-retry-after-budget, con17-mcp-pagination, con18-wss-sweep-exit - Unit 3 (projection/docs): projection-truthfulness, mcp-batch-cap, gw16-status-drift - Unit 4 (spec-import): yaml-normalization, oai13-path-item-wildcards, import-loudness-cluster, js01-placeholder-check, fwd17-19-contract-decisions - Unit 5 (WS polish + tests): con18b-ws-polish, client-policy-wire-tests, cov-deployment-knobs, cov13-dead-code, srv11-srv12-router-ordering - review-002-bracketed-followup: tentatively planned post-bulk pass (stale-check, OQA-18 enforcement decision, CON-08/09 close() lever, cross-crate re-checks) — deliberately not serialized against the bulk Also: review-002 numbering repair (CON-14 was double-booked; MCP pagination now CON-14, from_wss monitor renumbered CON-18, missing CON-14 section added). taskgraph: 66 valid, no cycles; 24 pending (all review-002); gen-1/gen-2 parallel waves identified; workflow-cost hotspots are prj16 (12.8) and ws13 (11.1), both carrying the reviewed slicing guidance in their Notes.
This commit is contained in:
@@ -0,0 +1,77 @@
|
||||
---
|
||||
id: review-002-gw15-publish-body-cap
|
||||
name: Cap /publish body buffering pre-newline + explicit body-limit layer (GW-15)
|
||||
status: pending
|
||||
depends_on: []
|
||||
scope: moderate
|
||||
risk: medium
|
||||
impact: component
|
||||
level: implementation
|
||||
tags: [gateway, review-002, security]
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Review 002 GW-15 [major] — `/publish` lost both claimed memory bounds
|
||||
in the GW-06 streaming rewrite. Verified at tree `91483a7`:
|
||||
|
||||
1. **No body limit on the route.** `publish_handler` takes raw
|
||||
`axum::body::Body` (`src/gateway/routes.rs:249-253`). axum's
|
||||
2 MiB `DefaultBodyLimit` is a request *extension* consulted only by
|
||||
extractors (axum-core `request_parts.rs` returns the raw body
|
||||
untouched) — a raw-Body handler has **no** default limit. The
|
||||
module doc's claim ("in addition to axum's own 2 MiB default body
|
||||
limit") is false on this route.
|
||||
2. **Unbounded line buffer.** `BufferedLines::next_line`
|
||||
(`routes.rs:425-448`) enforces `MAX_PUBLISH_LINE_BYTES` only when a
|
||||
`\n` is found; bytes accumulate in `self.buffer` unboundedly until
|
||||
then, and the trailing-EOF `std::mem::take(&mut self.buffer)` path
|
||||
has no cap check at all.
|
||||
|
||||
Concrete failure: unauthenticated `POST /publish` with chunked
|
||||
transfer-encoding streaming `'a'` forever (no newline) → heap grows
|
||||
with the upload until OOM; each poll also re-scans the whole buffer
|
||||
from index 0 → O(n²) CPU on top. This is the SRV-03 class one route
|
||||
over (SRV-03 fixed `/mcp`; `/publish` regressed into the same class
|
||||
via the streaming rewrite).
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] `BufferedLines` errors (terminal `LineError::LineCap` → the same
|
||||
INVALID_INPUT family the line-cap error uses today) once
|
||||
`self.buffer.len() > MAX_PUBLISH_LINE_BYTES`, checked *before*
|
||||
extending, even with no newline seen — the trailing-EOF
|
||||
`mem::take` path cannot exceed the cap
|
||||
- [ ] The publish route (or the whole gateway router) carries an
|
||||
explicit request-body-limit layer so it does not depend on
|
||||
extractor-side defaults for raw-Body handlers (size = the 2 MiB
|
||||
convention; note in module doc)
|
||||
- [ ] Wire test: chunked upload with no `"\n"` for > cap bytes is
|
||||
rejected with the documented status/body (not 200, not OOM)
|
||||
- [ ] Wire test: EOF without newline after > cap buffered bytes also
|
||||
rejected (the `mem::take` path)
|
||||
- [ ] Existing publish tests still pass (first-line handling, NDJSON
|
||||
streaming, schema validation, caps on terminated lines)
|
||||
- [ ] `cargo test`, `cargo clippy --all-targets -- -D warnings`,
|
||||
`cargo fmt --check` pass
|
||||
|
||||
## References
|
||||
|
||||
- docs/reviews/002-post-remediation-review.md (Part C', GW-15; Part G', COV-12 `BufferedLines` hot spot)
|
||||
- docs/architecture/decisions/068-gateway-publish-endpoint.md
|
||||
- src/gateway/routes.rs:249-253 (handler), 395-470 (BufferedLines)
|
||||
- tasks/gateway/review-001-publish-schema-validation-robust.md (the cache this must not stale)
|
||||
|
||||
## Notes
|
||||
|
||||
The line-cap test that exists today (`publish_line_exceeding_cap…`)
|
||||
short-circuits at the route level in single-chunk delivery — the new
|
||||
pre-extend check must be exercised with a **streamed** (multi-chunk,
|
||||
never-newline) body, which is the shape the old test cannot see. Keep
|
||||
`MAX_PUBLISH_LINE_BYTES` as the single cap constant; a separate total
|
||||
cap is optional (the layer limit bounds the total once landed).
|
||||
|
||||
GW-16 (the 400-vs-422 drift on the cap error's status) is deliberately
|
||||
NOT in scope here — see review-002-gw16-status-drift; land the cap with
|
||||
today's status first, then normalize statuses in that task to avoid
|
||||
churn in the same lines.
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
id: review-002-gw16-status-drift
|
||||
name: Unify INVALID_INPUT status on hand-rolled publish/batch paths + sink-deadline decision (GW-16, GW-17)
|
||||
status: pending
|
||||
depends_on: [review-002-gw15-publish-body-cap]
|
||||
scope: narrow
|
||||
risk: low
|
||||
impact: component
|
||||
level: implementation
|
||||
tags: [gateway, review-002]
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Two review-002 gateway status/deadline findings, same files
|
||||
(`routes.rs`, `dispatch.rs`), sequenced after the GW-15 body-cap task
|
||||
because GW-15 adds one more hand-rolled status site:
|
||||
|
||||
- **GW-16**: the documented mapping is `INVALID_INPUT → 422`
|
||||
(http-server.md:361), and mid-stream publish validation correctly
|
||||
emits 422. But the new pre-dispatch paths hand-build
|
||||
`CallError::invalid_input`-shaped responses with
|
||||
`StatusCode::BAD_REQUEST`: empty body, missing `operation`, missing
|
||||
`chunk`, invalid first-line JSON (:257-278), the line-cap error
|
||||
(:459-464), and the `/batch` over-cap reject (:173-184). Same error
|
||||
class, two statuses depending on where it fires — the GW-03 drift
|
||||
class one table row down.
|
||||
- **GW-17**: the documented 30 s deadline includes "the `/publish`
|
||||
final envelope" (http-server.md:381-384) but `invoke_sink` has no
|
||||
timeout (`dispatch.rs:132-145`) — the module doc justifies it as
|
||||
"bounded by the client's upload," which bounds chunk arrival, not
|
||||
the handler's final await. A hung sink handler parks the HTTP
|
||||
connection forever.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Decide + implement the body-shape-fault status: either (a) route
|
||||
all hand-rolled `INVALID_INPUT` responses through
|
||||
`call_error_to_http_response_with_identity` (making them 422
|
||||
like the documented mapping), or (b) sanction 400-for-body-shape
|
||||
in http-server.md's table explicitly (documenting which paths
|
||||
are "request shape" vs "per-chunk shape"). Implementer's choice;
|
||||
whichever it is, `/publish` and `/batch` agree and the doc table
|
||||
names both statuses' trigger conditions.
|
||||
- [ ] GW-17: decide + implement: (a) wrap the sink handler's
|
||||
completion in the same 30 s `tokio::time::timeout` family the
|
||||
Once-op invoke uses (new error envelope on trip), or (b) amend
|
||||
http-server.md to exclude the final envelope from the deadline
|
||||
contract. Prefer (a) — the documented contract is the older
|
||||
decision and hung-forever requests are the failure mode review
|
||||
001 filed twice.
|
||||
- [ ] Tests: each hand-rolled path's status asserted (publish
|
||||
first-line/empty/line-cap/batch-cap); sink-deadline test with a
|
||||
hung sink handler (mirroring dispatch.rs's hung-handler test)
|
||||
if (a)
|
||||
- [ ] http-server.md error/deadline tables updated to match the
|
||||
implemented choice
|
||||
- [ ] `cargo test`, `cargo clippy --all-targets -- -D warnings`,
|
||||
`cargo fmt --check` pass
|
||||
|
||||
## References
|
||||
|
||||
- docs/reviews/002-post-remediation-review.md (Part C', GW-16, GW-17)
|
||||
- src/gateway/routes.rs:173-184, 257-278, 459-464 (the hand-rolled 400s), dispatch.rs:132-145 (the sink await), error.rs:51 (the 422 mapping)
|
||||
- docs/architecture/http-server.md:361 (the error table), :381-388 (the deadline contract)
|
||||
- tasks/gateway/review-002-gw15-publish-body-cap.md (lands the line-cap error this task then normalizes)
|
||||
|
||||
## Notes
|
||||
|
||||
Do this after GW-15 so the line-cap path's final status is chosen once
|
||||
(avoid two commits churning the same lines). ADR-023 governs the
|
||||
error-code discipline — if (b) is chosen for GW-16, note the
|
||||
body-shape-vs-chunk-shape distinction there or in http-server.md so
|
||||
the next projection refresh captures it.
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
id: review-002-prj16-schema-via-call
|
||||
name: Block Internal-op schema disclosure via services/schema over /call (PRJ-16, cross-crate CF-004)
|
||||
status: pending
|
||||
depends_on: []
|
||||
scope: moderate
|
||||
risk: medium
|
||||
impact: project
|
||||
level: implementation
|
||||
tags: [gateway, security, review-002, cross-crate]
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Review 002 PRJ-16 [major, security]. Internal/ACL-restricted op specs
|
||||
are readable through the *op* path even though the GET `/schema` route
|
||||
was fixed in review-001 (SRV-02):
|
||||
|
||||
- `call_handler` (`src/gateway/routes.rs:120-133`) pre-checks only the
|
||||
**outer** op name — `services/schema` is External with default ACL,
|
||||
so the pre-check passes.
|
||||
- `registry.invoke` dispatches to alkcall's `services_schema_handler`
|
||||
(`alkcall src/registry/discovery.rs:327-343`), which does a bare
|
||||
`registry.registration(name)` → `spec_to_json` with **no visibility
|
||||
and no AccessControl check**.
|
||||
|
||||
`POST /call {"operation":"services/schema","input":{"name":"secret/op"}}`
|
||||
→ the full spec (input/output/error schemas + required_scopes) of any
|
||||
Internal op, unauthenticated. Same hole via the MCP `call` tool. The
|
||||
regenerated to_openapi doc asserts "Internal (hidden from HTTP
|
||||
discovery, GW-02)" — currently false at runtime. The alkcall-side
|
||||
instance is filed as **CF-004** in
|
||||
`alkcall/docs/reviews/consumer-findings-ledger.md` (the handler-level
|
||||
fix there is the complete one; this task is the alkhttp-local layer).
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] alkhttp-side guard: before dispatch, when the requested
|
||||
operation resolves to a `services/schema`-family handler, apply
|
||||
the same is_internal_op + access_check_for_op pre-checks to the
|
||||
**inner `name` input** as GET `/schema` does (404 for Internal,
|
||||
403 for ACL denial, mirroring routes.rs:151-156)
|
||||
- [ ] Implementer's choice on mechanism (options: a dispatch-path hook
|
||||
in `call_handler`/`batch_handler`/`subscribe_handler`; an
|
||||
alkhttp-side wrapper around the registry that intercepts
|
||||
`services/schema` inputs; a GatewayDispatch-level check) — the
|
||||
invariant is transport-level: **no alkhttp transport may fetch a
|
||||
spec the GET `/schema` route would deny for the same identity**
|
||||
- [ ] Test matrix mirroring the GET /schema tests: `/call` on
|
||||
services/schema{internal-op} → 404; unauthorized identity →
|
||||
403; MCP `call` tool with the same input → same result
|
||||
(feature-gated `mcp` test)
|
||||
- [ ] A comment/ADR-note recording that the complete fix is
|
||||
alkcall-side (CF-004) and this task is the local layer — when
|
||||
CF-004 lands, the alkhttp guard becomes defense-in-depth (do NOT
|
||||
remove it; the per-transport check stays)
|
||||
- [ ] `cargo test`, `cargo clippy --all-targets -- -D warnings`,
|
||||
`cargo fmt --check` pass (plus `--all-features` if the mcp test lands)
|
||||
|
||||
## References
|
||||
|
||||
- docs/reviews/002-post-remediation-review.md (Part F', PRJ-16)
|
||||
- alkcall/docs/reviews/consumer-findings-ledger.md (CF-004, filed 2026-08-30)
|
||||
- alkcall/src/registry/discovery.rs:327-343 (the unchecked handler)
|
||||
- src/gateway/routes.rs:120-133 (outer-name-only pre-check), 151-156 (the correct GET /schema checks to mirror)
|
||||
- docs/architecture/decisions/015-privilege-model-and-authority-context.md
|
||||
|
||||
## Notes
|
||||
|
||||
The three gateway invoke routes (`/call`, `/batch`, `/subscribe`) all
|
||||
dispatch through the same spine, so a single interception point (if
|
||||
found) covers all three + MCP; if the mechanism is route-local, mirror
|
||||
it in all three pre-check sites. Do not block on the alkcall fix —
|
||||
this task is shippable independently and the alkcall lead time is
|
||||
unknown. If CF-004 lands first, re-scope this task to defense-in-depth
|
||||
assertions only.
|
||||
Reference in New Issue
Block a user