Repository navigation
Conversation
Brook's writer uses records of the stream service across packages. The match takes the package and the interface, since several samples share `temporal:nexus`.
moetemp
force-pushed
the
moe/up/proto3-empty-string
branch
from
October 27, 2026 18:48
07890cb to
e87464a
Compare
The samples now generate what Brook generates, byte for byte from its WIT. No SDK has the Stream protos yet, so the sample projects ship their bindings. Today only part of the output builds, and each fix turns its part on.
…today's output. Today's Python and TypeScript generation panics on it, so their outputs keep their previous content. .NET types each case as the raw proto message, not as its record.
Variant planning kept such a case as the raw proto message. Python and TypeScript then panicked on a message conversion that wasn't model-shaped, and .NET typed the case as the proto class. The case now plans as the record, as a record field already does. Brook's stream service now generates for TypeScript, and its .NET read item holds the records.
A proto in temporal/... always became a temporalio module, so a proto that the SDK doesn't have yet couldn't be imported. --python-proto-module, and python_proto_modules in examples.toml, map a file path prefix to the module that replaces it. Brook's stream service now generates for Python, with the Stream protos from the sample's own package.
A proto `uint64` field was planned as a signed `s64`, so .NET typed it as `long` against the `ulong` of its proto class and the model didn't compile. The `writer-id` of Brook's writer sample shows the fix, and the writer now builds for .NET.
A proto-backed request holds a 64-bit integer as a `Long`, but a resource method takes a number. The method body converts its 64-bit params and fields, and lists of them. A `u64` becomes an unsigned `Long`. Brook's stream service now type-checks.
…ay's error. On native, Brook's empty `stream-id` asks the server for an id, and `CreateStreamRequest.stream_id` is a plain proto3 `string`. Python and TypeScript reject an empty id today, so the tests expect that error.
Python and TypeScript rejected an empty `string` or `bytes` field without presence as a missing required field. Such a field has no presence, so empty is the same as unset. The decoders now accept it, and TypeScript reads an unset field as empty. A native create with Brook's empty `stream-id`, which asks the server for an id, now decodes.
moetemp
force-pushed
the
moe/up/proto3-empty-string
branch
from
October 28, 2026 00:21
e87464a to
94dd887
Compare
Contributor
Author
|
Closing this. It drops nexgen's documented rule that a required string is non-empty, and it hides a missing proto2 string. Brook doesn't need it, since its |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed?
This PR makes the generated Python and TypeScript decoders accept an empty proto3
stringorbytesfield that has no presence.The first commit adds tests to the
stream-servicesample, Brook's Stream service, that decode aCreateStreamRequestwith an emptystream_id. They expect today's error. The second commit isthe fix, so its diff shows only what it changes.
if not value.<field>check.proto.<field> ?? ""(or?? new Uint8Array()forbytes), where it wrappedthe field in
requiredField.Message fields,
optionalfields andoneofmembers keep their presence check.Why?
A plain proto3 scalar has no presence, so
""is the same as unset. But a WITstringbound tosuch a field decoded
""as a missing required field in Python and TypeScript.Brook's Stream service hits it. Its
create-stream-requesthasstream-id: string, bound to aplain
string stream_idintemporalio/api#895. On native, an empty id asks the server for one.So a Stream handler couldn't decode such a create.
TypeScript also reads a field that isn't there as empty, since proto3 JSON leaves out a field
that has its default value.
How did you test it?
New Python and TypeScript tests decode a
CreateStreamRequestwith an emptystream_id, as aStream handler does. The TypeScript test also decodes one without a
streamIdkey, and the Pythontest encodes the request back to the same wire message.
It sits on #296. The stack is #308, #310, #311, #297, #296, then this PR.
cargo validatepasses.