Claude/turbo dotnet 10 upgrade 5fdy5j - #21
Merged
Conversation
Domain and plugin-infrastructure failures were signalled with BCL exceptions carrying interpolated messages, so callers could only react by matching on message text. Each failure now has a type that carries its data as properties and composes its own message. Plugin loading (Turbo.Plugins/Exceptions/): - PluginException, an abstract base carrying PluginKey, so a caller can catch any plugin problem uniformly. - PluginManifestException (NotFound / Unreadable / MissingField) with ManifestPath and FieldName. - PluginAssemblyException (NotFound / EntryPointNotFound / KeyMismatch) with AssemblyLocation and EntryPointKey. - PluginDependencyException (Missing / Cycle / DependentsActive / DependencyInactive) with the related keys. - PluginExportNotBoundException with the export type. Domain failures: - WalletDebitFailedException carries CurrencyKind plus the requested and applied amounts, replacing a bare Exception in PlayerWalletGrain. - CatalogTypeNotSupportedException carries the CatalogType. - RoomModelNotFoundException carries ModelId; RoomModelDataInvalidException carries the reason. - WiredParamTypeMismatchException carries the index and both types. - InvalidActionContextException carries the rejected context type. It lives in Turbo.Primitives rather than using TurboException, because Turbo.Primitives has no project references and TurboException is defined in Turbo.Logging, which depends on it. Two sites had no data worth carrying and use the existing coded pattern instead: the wired comparison switch now throws TurboException(TurboErrorCodeEnum.InvalidWired). The manifest parse handler gained a `when (ex is not PluginManifestException)` filter so the specific validation failures thrown inside the try are no longer re-wrapped as a generic parse error. BCL argument guards are deliberately untouched: ArgumentException and ArgumentOutOfRangeException remain correct for parameter validation, and Turbo.Runtime.AssemblyProcessing stays on BCL types since it cannot reference Turbo.Plugins. Clean quality gate on SDK 10.0.400: 0 errors, warning count unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H1WWL4hLiAvJr2jzxoGyaP
The 500ms avatar walk boundary was being hit late by a varying amount each cycle, which shows up in game as choppy walking: consecutive UserUpdateMessageComposer packets arrived anywhere from ~400ms to ~600ms apart. Two independent sources of jitter: 1. The room stream is a pull-based memory stream, and the pulling agent polls its queue every 100ms by default (GetQueueMsgsTimerPeriod). Since walk updates arrive 500ms apart, the agent is always idle when one is published, so every room packet paid a random 0-100ms queue wait. The room stream provider now polls every 10ms. 2. The room tick used a periodic grain timer, and Orleans measures a grain timer's period from the completion of the previous callback, so the effective cadence was RoomTickMs plus the tick body's execution time and the phase drifted continuously relative to the epoch-aligned boundary grid. The timer is now one-shot and re-arms itself to the next epoch-aligned RoomTickMs boundary after each tick (IGrainTimer.Change), so ticks land on the avatar/wired/roller boundaries within scheduler noise. The re-arm sits in a finally block so a failed tick cannot kill the room's tick loop, and a re-arm that lands exactly on a boundary is pushed a full period to avoid double-ticking it. Verified with the full quality gate on SDK 10.0.400: 0 errors, warning count unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H1WWL4hLiAvJr2jzxoGyaP
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
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
2 participants
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.
No description provided.