glm-5.3-flash
eaf1a203bc
Spike against alkcall source resolved ADR-067 assumptions: - write_chunk issues header+payload as separate write_alls; channel 0's write_frame issues prefix+body separately — a logical write can surface as multiple chunks, so the WS adapter must parse outgoing chunk boundaries (byte-stream treatment both directions), not assume write-per-chunk or message-per-chunk - MAX_CHUNK_LEN is 16 MiB; the WS path needs a practical message cap with oversized chunks split across messages - install_channel_zero + run_loop_single_stream confirmed as the exact server-side seam; EOF/teardown invariants already specified by alkcall (REQ-CH-01/02) Corrections applied to websocket.md, ADR-067, OQ-01. docs/plans/implementation.md: scoped plan guiding task decomposition — spike findings, 4-phase build order, OQ dispositions, task conventions.
5.5 KiB
5.5 KiB
Open Questions
Centralized tracker. Format follows the SDD process
(docs/sdd_process.md §Open Questions Format). Ported alknet OQs that
resolved before the extraction are recorded in the resolved section
with their resolutions; new alkhttp OQs start at OQ-01.
Status legend
open | resolved | deferred(scope) | partially resolved
Open
OQ-01: WS ↔ byte-stream adaptation semantics
- Origin: websocket.md, ADR-067
- Status: open
- Priority: high
- Question: The channels demux consumes bytes (
read_exacton the 8-byte header + payload); the mux writes chunks as contiguous byte sequences. A WebSocket is message-oriented. The adapter's contract needs nailing down before implementation: (a) inbound buffer bound (bounded channel between the WS read task and theAsyncReadhalf — what bound, what policy on overflow); (b) write-side chunk boundary parsing (verified against alkcall source: the mux emits one mpsc payload per chunk, but a logical write above the mux — e.g. channel 0'swrite_frame, which issues prefix and body as separatewrite_alls — can surface as multiple chunks; the adapter must parse outgoing chunk headers rather than assume write-per-chunk; also confirm the WS-message cap policy for chunks up toMAX_CHUNK_LEN= 16 MiB — split across messages, and what the practical cap is for browser stacks); (c) flush mapping (AsyncWrite::flush→ WS message emission point); (d) close mapping (WS close code → transport EOF → REQ-CH-02 teardown;AsyncWrite::shutdownmaps to the zero-length EOF sentinel (REQ-CH-01) then a WS Close frame — confirm this ordering against the mux's pump-exit behavior). - Blocked on: nothing (the spike resolved the factual sub-questions; the remaining items are implementation decisions to lock during the WS adapter task)
OQ-02: /publish body framing details
- Origin: ADR-068
- Status: open
- Priority: medium
- Resolution: (pending)
- Question: The exact first-line convention for naming the target
operation (first line
{operation, chunk}vs?operation=query parameter vs required header), and where a terminal error envelope lives (final NDJSON line of a JSON error object vs plain HTTP status with JSON body). Must settle before the gateway contract'sinfo.versionbumps (ADR-045).
OQ-03: from_wss reconnection semantics
- Origin: ADR-070
- Status: open
- Priority: medium
- Resolution: (pending)
- Question: On a dropped WSS connection, does
from_wssauto-reconnect + re-discover (services/list) + reconcile imported registrations, or does v1 surface call failures (INTERNAL, retryable) and leave the policy to the assembly layer? The v1 default (fail with retryable errors) is documented in ADR-070; the question is whether a built-in policy is ever warranted.
OQ-04: Browser client library ownership
- Origin: websocket.md
- Status: open
- Priority: low
- Blocked on: a concrete browser consumer (the alk UI) needing the
JS/TS client for channels-over-WS. The framing contract is the
alkcall BAST document (
chunk-header.bast.json); the client library lives outside this crate. Deferred(scope: browser UI work).
Resolved (ported)
Resolutions inherited from the alknet architecture; recorded here for reference. Full rationale in the alknet mono-repo's open-questions.md and the cited ADRs.
| OQ (alknet) | Title | Resolution | Where it lives now |
|---|---|---|---|
| OQ-11 | Handler-level auth resolution observability | Resolved: resolved identity stored on Connection via set_identity |
alkcall core; http-server.md §Auth |
| OQ-13 | Operation path format | Resolved: /{service}/{op} is the operation path format (gateway bodies carry it; no direct-call surface) |
ADR-036, ADR-047 |
| OQ-17 | Call protocol client and adapter contract | Resolved: OperationAdapter async trait; to_* projections |
alkcall ADR-022; ADR-017 |
| OQ-24 / OQ-26 | Operation error schemas / AdapterError variants |
Resolved: protocol/operation codes distinct; HTTP_<status> prefix; AdapterError #[non_exhaustive] |
alkcall ADR-016; ADR-023 |
| OQ-37 | X.509 outgoing-only / three peer roles | Resolved: browsers are not peers | ADR-034 |
| OQ-39 | to_openapi published-spec versioning |
Resolved: info.version semver tracks the gateway endpoint contract |
ADR-045 |
| OQ-40 | reqwest client config and connection pooling | Resolved: ClientWithMiddleware + retry + Retry-After middleware; rebuild-and-swap |
http-adapters.md §HTTP client |
| OQ-12 | TLS identity provisioning | Resolved (alknet): browsers require X.509; provisioning itself is an alknet concern | ADR-027; ADR-069 |
Not carried: OQ-38 (WebTransport standalone relay scope) — moot here; the relay is an alknet concern (ADR-069).