Skip to content

Bump Microsoft.Orleans.Streaming from 10.2.0 to 10.3.1 - #32

Merged
Mystikweb merged 10 commits into
mainfrom
dependabot/nuget/Microsoft.Orleans.Streaming-10.3.1
Sep 22, 2026
Merged

Mystikweb merged 10 commits into
mainfrom
dependabot/nuget/Microsoft.Orleans.Streaming-10.3.1

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Sep 22, 2026

Copy link
Copy Markdown
Contributor

Pinned Microsoft.Orleans.Streaming at 10.3.1.

Release notes

Sourced from Microsoft.Orleans.Streaming's releases.

10.3.1

The most significant change in this release over 10.3.0 is the format used by the version contract compatibility analyzers. The other changes are test and docs fixes.

What's Changed

Full Changelog: dotnet/orleans@v10.3.0...v10.3.1

10.3.0

Orleans 10.3.0

Orleans 10.3.0 expands the platform across clustering, streaming, persistence, integrations, serialization, and developer tooling while delivering a broad reliability and performance pass. Major outcomes include stronger distributed-directory and membership behavior, new streaming and storage providers, hardened transactions and durable jobs, incremental source generation, safer JSON storage deserialization, and new application templates. Alongside these features and fixes, the release optimizes key runtime paths, comprehensively refreshes the docs, strengthens testing and CI, and updates dependencies and repository maintenance.

Compatibility notes

[!IMPORTANT]
Review these changes before upgrading. This release contains three intentionally behavior-changing updates.

  • Default JSON storage serializer type allow-list (#​10268). The default Newtonsoft.Json-based Orleans storage serializer now resolves $type metadata only for types permitted by Orleans' configured type filters and manifest. Existing wire data remains readable when its types are allowed; [GenerateSerializer] types and standard permitted BCL types continue to work without changes. If persisted, streamed, or transactional JSON contains other types, reads now fail with an actionable JsonSerializationException. Prefer registering those types through TypeManifestOptions.AllowedTypes, [GenerateSerializer], ITypeNameFilter, or ITypeFilter; OrleansJsonSerializerOptions.AllowAllTypes = true restores the former permissive JSON behavior when a narrowly scoped allow-list is not practical.
  • Updated RPC semantic convention keys (#​10354). Orleans activities now emit the current OpenTelemetry RPC key rpc.system.name; Orleans-specific service, target, and source metadata move to orleans.rpc.service, orleans.rpc.target_id, and orleans.rpc.source_id. The runtime-side rpc.method value is now qualified as <interface>/<method>, and affected ActivitySource versions are incremented. Update dashboards, alerts, collectors, and queries which depend on the legacy rpc.system, rpc.service, rpc.orleans.target_id, or rpc.orleans.source_id keys or the previous method value.
  • Grain context configured before construction (#​10565). Orleans now deterministically applies IConfigureGrainContext actions before grain construction, so constructors can observe fully configured context state. Custom IGrainContextActivator implementations must migrate from CreateContext(GrainAddress) to CreateContext(GrainAddress, IConfigureGrainContext[]) and apply the supplied configurators before constructing the grain. Stateless-worker configurators continue to apply to the outer stateless-worker context.

Highlights

Runtime, clustering & resilience

Streaming

Storage, persistence, journaling, durable jobs & transactions

Providers & integrations

Serialization, code generation & analyzers

  • The source generator is now incremental, generates provider metadata at build time, avoids runtime provider scanning, and supports record-parameter field IDs and custom grain-call return types (#​10035, #​10493, #​10566, #​10495, #​10682).
  • Serialization reduces codec and buffer allocations, adds type/assembly allow-list helpers, and clarifies type-trust configuration (#​10301, #​10340, #​10668, #​10228, #​10424).
  • Analyzers detect RPC contract changes and provide improved diagnostic guidance (#​10337, #​10832).

Developer experience, templates, samples & docs

10.3.0-rc.1

What's Changed

10.2.2

What's Changed

New Contributors

10.2.2-rc.2

What's Changed

Full Changelog: dotnet/orleans@v10.2.2-rc.1...v10.2.2-rc.2

10.2.2-rc.1

What's Changed

New Contributors

Full Changelog: dotnet/orleans@v10.2.0...v10.2.2-rc.1

10.2.1

Reverts the message destination receiver cache changes from dotnet/orleans#10064 (commit: dotnet/orleans@d3c2af3)

Full Changelog: dotnet/orleans@v10.2.0...v10.2.1

Commits viewable in compare view.

@dependabot dependabot Bot added .NET Pull requests that update .NET code dependencies Pull requests that update a dependency file labels Sep 22, 2026
@Mystikweb
Mystikweb requested a lite review from Copilot September 22, 2026 15:30
---
updated-dependencies:
- dependency-name: Microsoft.Orleans.Streaming
  dependency-version: 10.3.1
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot force-pushed the dependabot/nuget/Microsoft.Orleans.Streaming-10.3.1 branch from 5208437 to feb4106 Compare September 22, 2026 15:31

Copilot AI left a comment

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.

Copilot review overview

🟡 Changes recommended

Align the related Orleans package versions or document a supported mixed-version configuration.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 Medium severity

Open (1)
What changed in this PR

Updates Microsoft.Orleans.Streaming from 10.2.0 to 10.3.1.

Changes:

  • Bumps the centrally managed streaming package version.
File Description
Directory.Packages.props Updates Orleans Streaming to 10.3.1 while related Orleans packages remain at 10.2.0.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread Directory.Packages.props
…ainers.Kafka to 4.15.0; enhance null handling in deserialization and update method signatures for cancellation support in Kafka integration tests.

Copilot AI left a comment

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.

Copilot review overview

🟡 Changes recommended

Cancellation tokens are currently ignored by the receiver during message polling and delivery.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 Medium severity

Open (1)
Resolved since last review (1)

Copilot AI left a comment

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.

Copilot review overview

🟡 Changes recommended

Cancellation can be ignored after idle polling, and the new cancellation behavior lacks focused test coverage.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 Low severity

Open (1)
Resolved since last review (1)

Comment thread src/Orleans.Streams.Confluent/KafkaQueueAdapterReceiver.cs

Copilot AI left a comment

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.

Copilot review overview

🟡 Changes recommended

Cancellation can advance Kafka positions and skip uncommitted records; the unrelated Testcontainers.Kafka upgrade also needs justification or separation.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 High severity

Open (1)
Resolved since last review (1)

Comment thread src/Orleans.Streams.Confluent/KafkaQueueAdapterReceiver.cs Outdated
…iveredAsync methods; add tests for cancellation handling in integration tests

Copilot AI left a comment

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.

Copilot review overview

🟡 Changes recommended

Three moderate issues remain in Kafka cancellation handling and rollback-path test coverage.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 2 Medium severity

Open (2)
Resolved since last review (1)

Comment thread src/Orleans.Streams.Confluent/KafkaQueueAdapterReceiver.cs Outdated
Comment thread src/Orleans.Streams.Confluent/KafkaQueueAdapterReceiver.cs Outdated
…for cancellation handling in MessagesDeliveredAsync

Copilot AI left a comment

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.

Copilot review overview

🟡 Changes recommended

Offset rollback can lose messages, and cancellation replay lacks the required regression coverage.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 High severity

Open (1)
Resolved since last review (2)

Comment thread src/Orleans.Streams.Confluent/KafkaQueueAdapterReceiver.cs Outdated
@Mystikweb
Mystikweb requested a lite review from Copilot September 22, 2026 18:06

Copilot AI left a comment

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.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Copilot AI left a comment

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.

Copilot review overview

🟡 Changes recommended

Unresolved critical and moderate findings affect offset safety and cancellable provider startup.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 High severity · 1 Low severity

Open (2)

Comment thread src/Orleans.Streams.Confluent/KafkaQueueAdapterReceiver.cs Outdated
Comment thread src/Orleans.Streams.Confluent/KafkaQueueAdapterReceiver.cs Outdated

Copilot AI left a comment

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.

Copilot review overview

🟡 Changes recommended

Unresolved cancellation and offset-handling issues remain, including a critical message-skipping risk.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 High severity

Open (1)
Resolved since last review (2)

Comment thread src/Orleans.Streams.Confluent/KafkaQueueAdapterReceiver.cs

Copilot AI left a comment

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.

Copilot review overview

🟡 Changes recommended

Cancellation handling, receiver fault-state behavior, and deterministic replay coverage remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 High severity

Open (1)
Resolved since last review (1)
Previously missed (2)

In code that hasn't changed since last review

Medium severity Honor cancellation after waiting for consumer lock

src/​Orleans.Streams.Confluent/​KafkaQueueAdapterReceiver.cs:87

Cancellation is checked before acquiring _consumerSync, but not again in this uninitialized branch. If the caller cancels while waiting for the lock, this returns an empty batch successfully instead of honoring cancellation; check the token immediately before returning the empty list.

This issue also appears in the following locations of the same file:

  • line 176
  • line 191
  • line 196
Medium severity Make cancellation timing deterministic in restoration test

test/​Orleans.Streams.Confluent.IntegrationTests/​KafkaStreamProviderIntegrationTests.cs:165

The 10 ms cancellation window is nondeterministic and may fire before Consume advances the receiver, allowing this test to pass without exercising read-side offset restoration or replay. Use a deterministic consumer seam/fake, or otherwise arrange cancellation after a poll and verify that the next read replays the batch.

Comment thread src/Orleans.Streams.Confluent/KafkaQueueAdapterReceiver.cs

Copilot AI left a comment

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.

Copilot review overview

🔵 Needs a closer look

Shutdown can lose an in-flight offset, and the integration test does not deterministically verify offset restoration.

Review effort: Lite
Findings: None

Resolved since last review (1)
Previously missed (1)

In code that hasn't changed since last review

Medium severity Make cancellation offset restoration test deterministic

test/​Orleans.Streams.Confluent.IntegrationTests/​KafkaStreamProviderIntegrationTests.cs:165

This test does not deterministically exercise cancellation after Kafka advances the consumer: the 10 ms timer can expire before the first Consume, so it still passes even if no offset is restored. Add a deterministic consumer seam or fake which cancels after a poll and verifies Seek/replay instead of relying on this timing window.

@Mystikweb
Mystikweb merged commit d3a2917 into main Sep 22, 2026
6 checks passed
@dependabot
dependabot Bot deleted the dependabot/nuget/Microsoft.Orleans.Streaming-10.3.1 branch September 22, 2026 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file .NET Pull requests that update .NET code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants