Repository navigation
Conversation
This was referenced Oct 23, 2026
Closed
moetemp
added a commit
to temporalio/nexgen
that referenced
this pull request
Oct 23, 2026
) ## What changed? This PR adds a `stream-service` sample for Python and TypeScript, with today's output. #272 adds .NET with its fix. It has a `stream` resource built from a ref, `create-stream`, append, read, describe and close, with 64-bit offsets, payloads and durations. Its records are proto-backed, as a stream service's are. Upstream has no stream protos, so the sample has its own small proto in `descriptors/streamsample/v1/`, with checked-in bindings. The samples README has the commands that regenerate them. `build_examples` now loads every `*.bin` under `descriptors/`. ## Why? Later fixes show their effect as a golden diff on this sample. ## How did you test it? The goldens. A TypeScript test sends a full `ReadRecordsRequest` through the converter, so the TypeScript type file can't drift from the proto. ## What comes next These fixes are ready, in this order. Each one adds its shape to this sample, then the fix. - #272: adds .NET, where the `stream` field of the `Stream` class fails with CS0542, then the fix. - [moetemp#52](moetemp#52): Check required resource fields of a response. Adds `create-stream` returning the `stream` resource. - [moetemp#56](moetemp#56): Allow a result record to hold a resource. Adds a `create-stream-result` holder record. - [moetemp#53](moetemp#53): Emit `@nexus.doc` on resources and methods as Python docstrings. - [moetemp#70](moetemp#70): Convert 64-bit resource method values to `Long` for a proto request in TypeScript. Adds 64-bit method parameters. Needs #265. - [moetemp#54](moetemp#54): Generate a Python caller per service over a transport. Turns on the client for the sample. - [moetemp#55](moetemp#55): Add `@nexus.long-poll` to the Python caller. Marks `read-records` as a long poll. - [moetemp#57](moetemp#57): Add Python client classes for resources with methods. - [moetemp#71](moetemp#71): Drop the bare keyword marker from a Python signature with no parameters. Adds a `stream-writer` interface with no endpoint. - [moetemp#60](moetemp#60): Indent the docstrings of Python caller methods. Adds a doc on a writer operation. - [moetemp#69](moetemp#69): Import record types that an endpoint-less Python client uses in unpacked parameters. Adds `open-writer`. - [moetemp#72](moetemp#72): Plan proto unsigned integers as unsigned. Adds a `uint64` writer id. - [moetemp#73](moetemp#73): Build a returned proto-wire resource in an endpoint-less TypeScript client. Makes `open-writer` return the `writer` resource. #262 adds a `status` enum to the holder record once it merges.
moetemp
force-pushed
the
moe/up/python-client-record-imports
branch
from
October 25, 2026 22:19
7fe0885 to
c3c1da4
Compare
moetemp
force-pushed
the
moe/up/proto-unsigned-ints
branch
from
October 25, 2026 22:19
3870c97 to
3e44798
Compare
moetemp
changed the base branch from
moe/up/python-client-record-imports
to
moe/brook/review/base
October 25, 2026 22:19
moetemp
marked this pull request as ready for review
October 25, 2026 23:49
moetemp
force-pushed
the
moe/up/proto-unsigned-ints
branch
from
October 26, 2026 20:56
3e44798 to
a2bfff7
Compare
moetemp
changed the base branch from
moe/brook/review/base
to
moe/brook/review/upstream-set
October 26, 2026 20:56
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 sample gets an endpoint-less writer with a `u64` writer id to show it.
moetemp
force-pushed
the
moe/up/proto-unsigned-ints
branch
from
October 26, 2026 22:37
a2bfff7 to
c00a0d9
Compare
moetemp
force-pushed
the
moe/brook/review/upstream-set
branch
from
October 26, 2026 22:37
ac6b723 to
68cc857
Compare
Owner
Author
|
Opened upstream as |
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.temporalio/nexgen#265added the unsigned types for WIT integers. This PR uses them for proto fields too.Longfor a 64-bit proto field.Depends on nothing. On the fork it's the bottom of the chain, on
moe/brook/review/upstream-set, so #73 (UPSTREAM-15) gets it from its base.Part of the Brook review series.
Why?
.NET typed a proto
uint64field aslong, but the proto class hasulong. So the model didn't compile.How did you test it?
The
stream-servicesample gets an endpoint-lessstream-writerwith auint64writer-id. Without the fix, the .NET model fails to build.Locally,
cargo validatepasses andcargo clippyadds no warnings. Fork CI doesn't run on this base.