-
Notifications
You must be signed in to change notification settings - Fork 183
WIP: ingestion API protocol #5024
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,113 @@ | ||
| // Copyright (c) 2026 - Restate Software, Inc., Restate GmbH | ||
| // | ||
| // This file is part of the Restate service protocol, which is | ||
| // released under the MIT license. | ||
| // | ||
| // You can find a copy of the license in file LICENSE in the root | ||
| // directory of this repository or package, or at | ||
| // https://github.com/restatedev/proto/blob/main/LICENSE | ||
|
|
||
| syntax = "proto3"; | ||
|
|
||
| package restate.ingestion; | ||
|
|
||
|
|
||
| // A Settings message defines the default values applied to all | ||
| // subsequent records in the stream. | ||
| // Each Settings message must specify every field it wants to set: | ||
| // its fields are not merged with those of previous Settings messages. | ||
| // Leaving an optional field unset clears any previously established | ||
| // default, so later records must supply the value explicitly if needed. | ||
| message Settings { | ||
| // required fields | ||
|
|
||
| // Unique producer ID for the stream. Deduplication relies on this | ||
| // ID being unique per ingestion stream | ||
| // (think Kafka cluster + topic + partition). | ||
| // An explicitly empty producer ID is valid but disables | ||
| // deduplication for the entire stream. | ||
| string producer_id = 1; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As the protocol stands, i can in theory change this value during the stream, sending another settings with a different producer_id, is it a good idea to allow this? |
||
|
|
||
| // optional fields | ||
| optional string scope = 2; | ||
| optional string limit_key = 3; | ||
| optional string service = 4; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. service key as well?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that's invocation specific
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it doesn't hurt to have it here imo, and it's free anyway. i can see a use case where you wanna send records to always the same key |
||
| optional string handler = 5; | ||
| map<string, string> headers = 6; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. do these sum with the Overrides? or Overrides replace them all? I think it makes sense they sum.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it merges with the defaults. So it doesn't replace them all. Only the set values |
||
| } | ||
|
|
||
| message Overrides { | ||
| } | ||
|
|
||
| message Record { | ||
| uint64 offset = 1; | ||
| // Required when the target service is a virtual object (VO). | ||
| optional string key = 2; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. or workflow |
||
| optional string traceparent = 3; | ||
| optional string tracestate = 4; | ||
|
Comment on lines
+46
to
+47
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. are these in format w3c tracecontext? if yes, can you please add it as comment? |
||
|
|
||
| // Overrides | ||
| optional string scope = 5; | ||
| optional string limit_key = 6; | ||
| optional string service = 7; | ||
| optional string handler = 8; | ||
| // These headers are merged with the default headers | ||
| // from the Settings message. | ||
| map<string, string> additional_headers = 9; | ||
|
|
||
| bytes payload = 100; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. up to 15 included you use one byte for the field varint, for a field that we're gonna always set use field numbers 1 -> 15 pls |
||
| } | ||
|
|
||
| message Request { | ||
| oneof payload { | ||
| Settings settings = 1; | ||
| Record record = 2; | ||
| } | ||
| } | ||
|
|
||
| // Application-layer flow control message. | ||
| // It tells the client how much more it can send | ||
| // before it must wait for the next window update. | ||
| // | ||
| // WindowUpdate also doubles as an explicit ack: the | ||
| // server can send an update with a 0 increment to | ||
| // acknowledge commits up to "Response::last_committed" | ||
| // without changing the window size. | ||
| message WindowUpdate { | ||
| uint64 increment = 1; | ||
| } | ||
|
|
||
| enum ErrorKind { | ||
| ERROR_KIND_UNKNOWN = 0; | ||
| // Server is shutting down and | ||
| // can't accept more records | ||
| ERROR_KIND_SHUTTING_DOWN = 1; | ||
| ERROR_KIND_UNKNOWN_SERVICE = 2; | ||
| ERROR_KIND_UNKNOWN_HANDLER = 3; | ||
| // add new error kinds here | ||
|
|
||
| } | ||
| message Error { | ||
| ErrorKind kind = 1; | ||
| string message = 2; | ||
| } | ||
|
Comment on lines
+90
to
+93
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. for the errors related to schema registry and co, how about we return an
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This way error handling can be unified among regular ingress usage and the ingress ingestion api
Comment on lines
+90
to
+93
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A related question here, what is the expectation for a client when receiving this Error message? that the server will afterwards tear down the stream? |
||
|
|
||
| message Response { | ||
| // Offsets are 0-based, so last_committed must be optional | ||
| // to distinguish "offset 0 committed" from "nothing committed yet". | ||
| // This matters when an error is returned on the first | ||
| // ingestion message. | ||
| optional uint64 last_committed = 1; | ||
|
|
||
| oneof response { | ||
| WindowUpdate ack = 2; | ||
| Error error = 3; | ||
| } | ||
| } | ||
|
|
||
| // Service that is only reachable on nodes that are alive. | ||
| service IngestionSvc { | ||
| // Opens a bidirectional node-to-node stream. | ||
| rpc Ingest(stream Request) | ||
| returns (stream Response); | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.