Skip to content

Added: V2 - stream management specification (fixes #109) - #110

Draft
kratz00 wants to merge 10 commits into
mainfrom
feature/stream_management_specification
Draft

kratz00 wants to merge 10 commits into
mainfrom
feature/stream_management_specification

Conversation

@kratz00

@kratz00 kratz00 commented Oct 28, 2026

Copy link
Copy Markdown
Collaborator

Fixes #109

@kratz00
kratz00 requested a deployment to v2-fuzzing-pr-approval October 28, 2026 12:17 — with GitHub Actions Waiting
@kratz00
kratz00 force-pushed the feature/stream_management_specification branch from f794845 to 9b743c1 Compare October 28, 2026 12:21
@kratz00
kratz00 requested a deployment to v2-fuzzing-pr-approval October 28, 2026 12:21 — with GitHub Actions Waiting
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
@kratz00
kratz00 force-pushed the feature/stream_management_specification branch from 9b743c1 to 161cf56 Compare October 28, 2026 12:25
@kratz00
kratz00 requested a deployment to v2-fuzzing-pr-approval October 28, 2026 12:25 — with GitHub Actions Waiting
Comment on lines +54 to +62
OutboundEnvelope {
StreamId stream_id // 0 for ControlMessageBuilder
CallMessageBuilder | ControlMessageBuilder builder
}

InboundEnvelope {
StreamId stream_id // 0 for ControlMessageView
CallMessageView | ControlMessageView view
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in theory the flatbuffer objects contain the stream id, so do we need this actually

- stream `0` goes to the control-stream pending list;
- an envelope for a known nonzero `stream_id` goes to that stream's pending
list;
- an opening message for a never-created odd stream creates an inbound-call

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we cant simply say odd, it depends on what kind of context we have


## Close and ID lifetime

The worker-owned call registry keeps a closed-stream set keyed by `stream_id`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to avoid storing all closed stream id. We already remember stream ids for open calls and we could remember the highest used stream id for each side and reject any messages for stream ids that are smaller and not open

# Conflicts:
#	doc/design/v2/runner/README.md
@kratz00
kratz00 requested a deployment to v2-fuzzing-pr-approval November 4, 2026 13:40 — with GitHub Actions Waiting
@kratz00
kratz00 requested a deployment to v2-fuzzing-pr-approval November 5, 2026 09:12 — with GitHub Actions Waiting
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
@kratz00
kratz00 requested a deployment to v2-fuzzing-pr-approval November 5, 2026 09:28 — with GitHub Actions Waiting
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
@kratz00
kratz00 requested a deployment to v2-fuzzing-pr-approval November 5, 2026 15:34 — with GitHub Actions Waiting
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
@kratz00
kratz00 requested a deployment to v2-fuzzing-pr-approval November 5, 2026 15:44 — with GitHub Actions Waiting
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
@kratz00
kratz00 requested a deployment to v2-fuzzing-pr-approval November 5, 2026 17:34 — with GitHub Actions Waiting
Signed-off-by: Steffen Pankratz <steffen.pankratz@exasol.com>
@kratz00
kratz00 requested a deployment to v2-fuzzing-pr-approval November 5, 2026 19:18 — with GitHub Actions Waiting
@sonarqubecloud

sonarqubecloud Bot commented Nov 5, 2026

Copy link
Copy Markdown

an abnormal call termination. Without `Error`, it is normal termination. After sending or receiving `CloseCall`, the
local endpoint sends no further call-scoped traffic on that stream. Messages already in transit may still arrive after
either event; the endpoint ignores those late stream messages while still processing a received `CloseCall`.
either event. The low-level context discards delayed messages for inactive peer-owned stream IDs as described in the

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

protocol does not know about the context

Sending or receiving `CloseCall` makes the local endpoint's outbound direction terminal: it sends no further schema,
batch, send budget, `Reset(...)`, or other call-scoped message. A `CloseCall` is not acknowledged. Messages already in flight may
still arrive after either endpoint sends or receives `CloseCall`; late messages for the closed stream are ignored.
still arrive after either endpoint sends or receives `CloseCall`. Delayed messages for inactive peer-owned stream IDs

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

protocol doesnt know about runner

The worker-owned call registry keeps a closed-stream set keyed by `stream_id`. Closing a call records its stream ID
before releasing its pending sequence, so delayed messages can be discarded without confusing them with a new call;
stream IDs are never reused on a connection.
The worker-owned call registry tracks active streams and the high-water state described in

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

worker owned sounds wrong

does not own `Call` or `ControlStream` instances and does not dispatch to
worker-facing objects.

## Stream-ID ownership and allocation

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this basically a copy from the protocol

This branch is waiting to be deployed

1 waiting deployment
v2-fuzzing-pr-approval — 56f288cf Waiting Nov 5, 2026 by kratz00 via pr_approval #319
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

V2 Runner: Create stream management specification

2 participants