Repository navigation
Conversation
moetemp
force-pushed
the
moe/up/proto-unsigned-ints
branch
5 times, most recently
from
October 27, 2026 00:19
5a2beda to
12b0bcd
Compare
1 of 3 tasks
moetemp
force-pushed
the
moe/up/proto-unsigned-ints
branch
2 times, most recently
from
October 27, 2026 17:43
b71a054 to
431dc01
Compare
1 of 3 tasks
moetemp
force-pushed
the
moe/up/proto-unsigned-ints
branch
from
October 27, 2026 18:35
431dc01 to
eac4079
Compare
moetemp
force-pushed
the
moe/up/proto-unsigned-ints
branch
from
October 28, 2026 00:21
eac4079 to
00379ac
Compare
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`.
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.
This is today's output. Python and TypeScript panic on the record cases, so their outputs keep their previous content. .NET types each case as the raw proto message, not as its record or enum. No Temporal API message has a oneof with an enum case, so the sample gets its own proto.
Variant planning kept such a case as the raw proto type. Python and TypeScript panicked on a record case, and named an enum case's type without defining it. .NET typed the case as the proto class or enum. The case now plans as the record or enum, 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. A prefix matches whole path segments, and the module must be a dotted Python name. 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.
moetemp
force-pushed
the
moe/up/proto-unsigned-ints
branch
from
October 28, 2026 16:37
00379ac to
cf23cbb
Compare
This was referenced Oct 28, 2026
This was referenced Oct 28, 2026
1 of 3 tasks
moetemp
force-pushed
the
moe/up/python-proto-modules
branch
from
October 29, 2026 04:00
92cfcc2 to
81fd8c7
Compare
Contributor
Author
|
Closing this. It fixes unsigned proto ints, but Brook doesn't need it anymore, because nexgen no longer generates the stream writer. |
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 plans a proto
uint32orfixed32field asu32, and auint64orfixed64field asu64. .NET then types it asuintorulong, as its proto class does.TypeScript keeps
Longfor a 64-bit proto field, and Python output doesn't change.It's based on #311.
Why?
.NET typed a proto
uint64field aslong, but the proto class hasulong, so the model didn't compile. Brook's writer has auint64writer-id, so the sample project left the .NET writer out of the build.How did you test it?
Link to a test plan if any -
cargo validatepasses, and the .NET sample project builds Brook's writer.