feat(command): align Result with .NET Eventuous, add Change type#3
feat(command): align Result with .NET Eventuous, add Change type#3alexeyzimarev merged 2 commits intomainfrom
Conversation
… event type names Replace Result.NewEvents ([]any) with Result.Changes ([]Change) where Change pairs each event with its registered TypeMap name. Both Service and AggregateService now accept *codec.TypeMap so they can resolve type names when building the result — matching the .NET Result<TState>.Ok shape (state, changes, globalPosition). StreamVersion is kept in Go and will be added to .NET later. Standardize booking sample HTTP API to return the same JSON envelope from all command endpoints, enabling UI portability between Go and .NET backends. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bcf46d23b9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
core/command/service.go
Outdated
| // Step 7: Build changes and fold new events into state. | ||
| changes := make([]Change, len(newEvents)) | ||
| for i, e := range newEvents { | ||
| typeName, _ := svc.typeMap.TypeName(e) |
There was a problem hiding this comment.
Guard TypeMap lookup failures when building Service changes
Handle now calls svc.typeMap.TypeName(e) without validating svc.typeMap or the lookup error. If a caller constructs command.New(..., nil, ...), this line panics on the first command that emits events; if an event type is missing from the map, the ignored error produces an empty eventType and violates the new response contract. This should fail fast with an explicit error instead of panicking or silently returning blank type names.
Useful? React with 👍 / 👎.
core/command/aggservice.go
Outdated
| // Step 9: Build typed changes and return result. | ||
| changes := make([]Change, len(rawChanges)) | ||
| for i, e := range rawChanges { | ||
| typeName, _ := svc.typeMap.TypeName(e) |
There was a problem hiding this comment.
Guard TypeMap lookup failures in AggregateService results
AggregateService.Handle has the same unchecked svc.typeMap.TypeName(e) call when materializing Result.Changes. A nil typeMap causes a runtime panic, and an unregistered event type is silently converted to eventType:"", so API clients can receive malformed change metadata even though the append succeeded. Returning a clear error here would avoid both crash and silent data-shape corruption.
Useful? React with 👍 / 👎.
Add nil check on TypeMap in constructors (panic on misconfiguration). Return error from Handle when TypeName lookup fails instead of silently producing empty eventType strings. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Summary
Result.NewEvents([]any) withResult.Changes([]Change) whereChangepairs each event with its registered TypeMap name — matching the .NETResult<TState>.OkshapeServiceandAggregateServicenow accept*codec.TypeMapto resolve type names when building resultsStreamVersionin Go Result (will be added to .NET later)Test plan
go test -race ./...)gofmtandgo vetclean across all modules🤖 Generated with Claude Code