diff --git a/website/src/docs/docs.json b/website/src/docs/docs.json index 62c559b5d06..72ebb784061 100644 --- a/website/src/docs/docs.json +++ b/website/src/docs/docs.json @@ -2866,11 +2866,11 @@ "title": "Mocha", "description": "Messaging Bus for .NET", "metaDescription": "Mocha is a messaging framework for .NET that combines simplicity, flexibility, and observability with deep Nitro integration.", - "latestStableVersion": "v1", + "latestStableVersion": "v16", "versions": [ { - "path": "v1", - "title": "v1", + "path": "v16", + "title": "v16", "items": [ { "path": "index", diff --git a/website/src/docs/mocha/v1/diagnostics.md b/website/src/docs/mocha/v16/diagnostics.md similarity index 92% rename from website/src/docs/mocha/v1/diagnostics.md rename to website/src/docs/mocha/v16/diagnostics.md index 782e39e1468..e36276b541e 100644 --- a/website/src/docs/mocha/v1/diagnostics.md +++ b/website/src/docs/mocha/v16/diagnostics.md @@ -23,7 +23,7 @@ Mocha uses a Roslyn source generator to validate your message handlers, consumer # Mediator diagnostics -These diagnostics apply to the in-process [mediator](/docs/mocha/v1/mediator) - commands, queries, and notifications dispatched within a single process. +These diagnostics apply to the in-process [mediator](/docs/mocha/v16/mediator) - commands, queries, and notifications dispatched within a single process. ## MO0001 @@ -129,7 +129,7 @@ public class PlaceOrderHandler : ICommandHandler ### Cause -A class implements a [handler](/docs/mocha/v1/handlers-and-consumers) interface (`ICommandHandler`, `IQueryHandler`, or `INotificationHandler`) but is declared `abstract`. The source generator skips abstract types because they cannot be instantiated. +A class implements a [handler](/docs/mocha/v16/handlers-and-consumers) interface (`ICommandHandler`, `IQueryHandler`, or `INotificationHandler`) but is declared `abstract`. The source generator skips abstract types because they cannot be instantiated. ### Example @@ -259,7 +259,7 @@ public class GetOrderHandler : IQueryHandler # Messaging diagnostics -These diagnostics apply to the [message bus](/docs/mocha/v1/handlers-and-consumers) - event handlers, request handlers, batch handlers, consumers, and sagas that communicate across service boundaries. +These diagnostics apply to the [message bus](/docs/mocha/v16/handlers-and-consumers) - event handlers, request handlers, batch handlers, consumers, and sagas that communicate across service boundaries. ## MO0011 @@ -272,7 +272,7 @@ These diagnostics apply to the [message bus](/docs/mocha/v1/handlers-and-consume ### Cause -A request type (used with `SendAsync` or `RequestAsync`) has more than one [handler](/docs/mocha/v1/handlers-and-consumers) implementation. Request types require exactly one handler - the bus cannot route to multiple targets. +A request type (used with `SendAsync` or `RequestAsync`) has more than one [handler](/docs/mocha/v16/handlers-and-consumers) implementation. Request types require exactly one handler - the bus cannot route to multiple targets. ### Example @@ -376,7 +376,7 @@ public class OrderPlacedHandler : IEventHandler ### Cause -A class implements a messaging [handler](/docs/mocha/v1/handlers-and-consumers) interface but is declared `abstract`. The source generator skips abstract types because they cannot be instantiated. +A class implements a messaging [handler](/docs/mocha/v16/handlers-and-consumers) interface but is declared `abstract`. The source generator skips abstract types because they cannot be instantiated. ### Example @@ -423,7 +423,7 @@ public class OrderPlacedHandler : IEventHandler ### Cause -A [`Saga`](/docs/mocha/v1/sagas) subclass does not have a public parameterless constructor. The saga infrastructure requires this constructor to instantiate the saga type. This is enforced by the `new()` constraint on the `AddSaga` registration method. +A [`Saga`](/docs/mocha/v16/sagas) subclass does not have a public parameterless constructor. The saga infrastructure requires this constructor to instantiate the saga type. This is enforced by the `new()` constraint on the `AddSaga` registration method. ### Example diff --git a/website/src/docs/mocha/v1/example.json b/website/src/docs/mocha/v16/example.json similarity index 100% rename from website/src/docs/mocha/v1/example.json rename to website/src/docs/mocha/v16/example.json diff --git a/website/src/docs/mocha/v1/exception-policies.md b/website/src/docs/mocha/v16/exception-policies.md similarity index 100% rename from website/src/docs/mocha/v1/exception-policies.md rename to website/src/docs/mocha/v16/exception-policies.md diff --git a/website/src/docs/mocha/v1/handler-registration.md b/website/src/docs/mocha/v16/handler-registration.md similarity index 85% rename from website/src/docs/mocha/v1/handler-registration.md rename to website/src/docs/mocha/v16/handler-registration.md index 5a5514d9b74..7cc243f4fc8 100644 --- a/website/src/docs/mocha/v1/handler-registration.md +++ b/website/src/docs/mocha/v16/handler-registration.md @@ -28,7 +28,7 @@ The generator discovers these types: | `IConsumer` | Low-level consumer | | `Saga` | Saga orchestration | -If you have used the [Mediator source generator](/docs/mocha/v1/mediator), this works the same way. The mediator generates `Add{ModuleName}()` on `IMediatorHostBuilder`; the message bus generates `Add{ModuleName}()` on `IMessageBusHostBuilder`. +If you have used the [Mediator source generator](/docs/mocha/v16/mediator), this works the same way. The mediator generates `Add{ModuleName}()` on `IMediatorHostBuilder`; the message bus generates `Add{ModuleName}()` on `IMessageBusHostBuilder`. > **Recommendation:** Always use the source generator for handler registration. The generated code uses optimized, reflection-free registration paths. The source-generated output is designed for long-term stability across versions. Manual registration methods are available for edge cases but their internal behavior may change between releases. @@ -91,15 +91,15 @@ If IntelliSense does not show `Add{ModuleName}()`: - Confirm the `Mocha.Analyzers` package is referenced with `OutputItemType="Analyzer"` in your `.csproj` - Rebuild the project - source generators run during compilation -- Check the build output for [analyzer diagnostics](/docs/mocha/v1/diagnostics) prefixed with `MO` +- Check the build output for [analyzer diagnostics](/docs/mocha/v16/diagnostics) prefixed with `MO` - Verify you have at least one concrete handler class in the assembly ## Handler is not being called If the source-generated method is available but a specific handler does not run: -- Check for [**MO0013**](/docs/mocha/v1/diagnostics#mo0013) (abstract handler) - only concrete classes are registered -- Check for [**MO0012**](/docs/mocha/v1/diagnostics#mo0012) (open generic) - close the generic type +- Check for [**MO0013**](/docs/mocha/v16/diagnostics#mo0013) (abstract handler) - only concrete classes are registered +- Check for [**MO0012**](/docs/mocha/v16/diagnostics#mo0012) (open generic) - close the generic type - Verify the handler implements the correct interface for the messaging pattern you are using - Ensure the handler is in the same project that references `Mocha.Analyzers` @@ -111,7 +111,7 @@ If a class implements more than one messaging interface (e.g., both `IBatchEvent # Next steps -- [Handlers and Consumers](/docs/mocha/v1/handlers-and-consumers) - handler interfaces, DI scoping, and exception behavior -- [Routing and Endpoints](/docs/mocha/v1/routing-and-endpoints) - how the bus routes messages to registered handlers -- [Sagas](/docs/mocha/v1/sagas) - saga state machines and long-running workflows -- [Mediator](/docs/mocha/v1/mediator) - the mediator uses the same source generation approach for in-process CQRS +- [Handlers and Consumers](/docs/mocha/v16/handlers-and-consumers) - handler interfaces, DI scoping, and exception behavior +- [Routing and Endpoints](/docs/mocha/v16/routing-and-endpoints) - how the bus routes messages to registered handlers +- [Sagas](/docs/mocha/v16/sagas) - saga state machines and long-running workflows +- [Mediator](/docs/mocha/v16/mediator) - the mediator uses the same source generation approach for in-process CQRS diff --git a/website/src/docs/mocha/v1/handlers-and-consumers.md b/website/src/docs/mocha/v16/handlers-and-consumers.md similarity index 95% rename from website/src/docs/mocha/v1/handlers-and-consumers.md rename to website/src/docs/mocha/v16/handlers-and-consumers.md index 065199bac8a..2a601f47785 100644 --- a/website/src/docs/mocha/v1/handlers-and-consumers.md +++ b/website/src/docs/mocha/v16/handlers-and-consumers.md @@ -19,7 +19,7 @@ Choose a handler interface based on the messaging pattern you are implementing: | `IBatchEventHandler` | Processing multiple events at once for throughput efficiency. | | `IConsumer` | Accessing raw envelope metadata - headers, correlation IDs, or the full consume context. | -If you have read [Messaging Patterns](/docs/mocha/v1/messaging-patterns), these map directly: `IEventHandler` is for `PublishAsync`, `IEventRequestHandler` is for `SendAsync`, and `IEventRequestHandler` is for `RequestAsync`. +If you have read [Messaging Patterns](/docs/mocha/v16/messaging-patterns), these map directly: `IEventHandler` is for `PublishAsync`, `IEventRequestHandler` is for `SendAsync`, and `IEventRequestHandler` is for `RequestAsync`. # Event handler @@ -87,7 +87,7 @@ var app = builder.Build(); app.Run(); ``` -`.AddMyApp()` is a source-generated extension method that discovers all handlers in the assembly and registers them. The source generator found `OrderPlacedHandler`, saw that it implements `IEventHandler`, and emitted a registration call for it. For details on how the source generator works and how to customize the module name, see [Handler Registration](/docs/mocha/v1/handler-registration). +`.AddMyApp()` is a source-generated extension method that discovers all handlers in the assembly and registers them. The source generator found `OrderPlacedHandler`, saw that it implements `IEventHandler`, and emitted a registration call for it. For details on how the source generator works and how to customize the module name, see [Handler Registration](/docs/mocha/v16/handler-registration). ## Verify the handler runs @@ -419,7 +419,7 @@ public class OrderAuditConsumer(ILogger logger) } ``` -`IConsumeContext` gives you the deserialized message plus envelope fields: `MessageId`, `CorrelationId`, `ConversationId`, `CausationId`, `SourceAddress`, `DestinationAddress`, `SentAt`, `Headers`, `DeliveryCount`, and more. See [Messages](/docs/mocha/v1/messages) for how correlation identifiers relate to each other. +`IConsumeContext` gives you the deserialized message plus envelope fields: `MessageId`, `CorrelationId`, `ConversationId`, `CausationId`, `SourceAddress`, `DestinationAddress`, `SentAt`, `Headers`, `DeliveryCount`, and more. See [Messages](/docs/mocha/v16/messages) for how correlation identifiers relate to each other. Register with `.AddConsumer()`: @@ -461,11 +461,11 @@ Singleton services are resolved from the root container as usual. If you inject When `HandleAsync` throws, the behavior depends on the handler type and the middleware pipeline: -- **Event handlers and send handlers:** The exception is caught by the pipeline. By default, Mocha retries the message according to the configured retry policy, then moves it to the dead-letter queue if retries are exhausted. See [Reliability](/docs/mocha/v1/reliability) for retry and fault configuration. +- **Event handlers and send handlers:** The exception is caught by the pipeline. By default, Mocha retries the message according to the configured retry policy, then moves it to the dead-letter queue if retries are exhausted. See [Reliability](/docs/mocha/v16/reliability) for retry and fault configuration. - **Request handlers:** The exception propagates back to the caller as a fault. If you use `RequestAsync`, it throws on the caller side. The caller receives the error, not a timeout. - **Batch handlers:** If the handler throws, all messages in the batch fault together. The pipeline treats the entire batch as a failed unit. -When a message arrives, it passes through middleware before reaching your handler. The pipeline handles fault routing, dead-letter delivery, observability, and concurrency limits - without any code in your handler. See [Middleware and Pipelines](/docs/mocha/v1/middleware-and-pipelines) for details on writing custom pipeline middleware. +When a message arrives, it passes through middleware before reaching your handler. The pipeline handles fault routing, dead-letter delivery, observability, and concurrency limits - without any code in your handler. See [Middleware and Pipelines](/docs/mocha/v16/middleware-and-pipelines) for details on writing custom pipeline middleware. # Publishing from a handler @@ -504,17 +504,17 @@ public class OrderPlacedHandler( } ``` -Messages published from within a handler automatically inherit the `ConversationId` and `CorrelationId` from the inbound message. The bus sets `CausationId` on the outgoing message to the `MessageId` of the inbound message. This creates a traceable parent-child chain across services without any extra code. See [Messages](/docs/mocha/v1/messages) for how correlation identifiers work. +Messages published from within a handler automatically inherit the `ConversationId` and `CorrelationId` from the inbound message. The bus sets `CausationId` on the outgoing message to the `MessageId` of the inbound message. This creates a traceable parent-child chain across services without any extra code. See [Messages](/docs/mocha/v16/messages) for how correlation identifiers work. # Further reading -- [Handler Registration](/docs/mocha/v1/handler-registration) - How the source generator discovers handlers and how to customize registration. +- [Handler Registration](/docs/mocha/v16/handler-registration) - How the source generator discovers handlers and how to customize registration. - [Event-Driven Consumer](https://www.enterpriseintegrationpatterns.com/patterns/messaging/EventDrivenConsumer.html) - The EIP pattern that defines push-based message consumption, which is what Mocha's handlers implement. - [Competing Consumers](https://www.enterpriseintegrationpatterns.com/patterns/messaging/CompetingConsumers.html) - When multiple instances of your service run, they compete for messages on the same queue. This is the concurrency model for Mocha handlers under load. # Next steps -Your handlers are registered. Learn how the source generator discovers and registers them in [Handler Registration](/docs/mocha/v1/handler-registration), or how Mocha routes messages to them in [Routing and Endpoints](/docs/mocha/v1/routing-and-endpoints). +Your handlers are registered. Learn how the source generator discovers and registers them in [Handler Registration](/docs/mocha/v16/handler-registration), or how Mocha routes messages to them in [Routing and Endpoints](/docs/mocha/v16/routing-and-endpoints). > **Runnable examples:** [BatchHandler](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/HandlersAndConsumers/BatchHandler), [LowLevelConsumer](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/HandlersAndConsumers/LowLevelConsumer), [CustomConsumer](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/HandlersAndConsumers/CustomConsumer) > diff --git a/website/src/docs/mocha/v1/hosting.md b/website/src/docs/mocha/v16/hosting.md similarity index 92% rename from website/src/docs/mocha/v1/hosting.md rename to website/src/docs/mocha/v16/hosting.md index c255a951042..dc70d55404f 100644 --- a/website/src/docs/mocha/v1/hosting.md +++ b/website/src/docs/mocha/v16/hosting.md @@ -113,6 +113,6 @@ The response is a JSON document describing the full bus topology: the host, regi # Next steps -- [Observability](/docs/mocha/v1/observability) - Add OpenTelemetry tracing and metrics to the bus. -- [Reliability](/docs/mocha/v1/reliability) - Configure outbox, inbox, and circuit breakers. -- [Transports](/docs/mocha/v1/transports) - Configure RabbitMQ, InMemory, and multi-transport setups. +- [Observability](/docs/mocha/v16/observability) - Add OpenTelemetry tracing and metrics to the bus. +- [Reliability](/docs/mocha/v16/reliability) - Configure outbox, inbox, and circuit breakers. +- [Transports](/docs/mocha/v16/transports) - Configure RabbitMQ, InMemory, and multi-transport setups. diff --git a/website/src/docs/mocha/v1/index.md b/website/src/docs/mocha/v16/index.md similarity index 97% rename from website/src/docs/mocha/v1/index.md rename to website/src/docs/mocha/v16/index.md index b87d46f3c26..205ef56dd65 100644 --- a/website/src/docs/mocha/v1/index.md +++ b/website/src/docs/mocha/v16/index.md @@ -45,7 +45,7 @@ These terms appear throughout the documentation. They are defined once here and | **Pipeline** | The chain of middleware that processes a message from the transport through to the handler. | | **Saga** | A long-running stateful workflow that coordinates multiple messages and transitions across services. | | **Mediator** | An in-process dispatcher that routes commands, queries, and notifications to their handlers without a transport layer. Source-generated at compile time. | -| **Source generator** | A Roslyn analyzer that discovers handlers and sagas at compile time and generates typed registration code. Used by both the [mediator](/docs/mocha/v1/mediator) and the [message bus](/docs/mocha/v1/handler-registration). | +| **Source generator** | A Roslyn analyzer that discovers handlers and sagas at compile time and generates typed registration code. Used by both the [mediator](/docs/mocha/v16/mediator) and the [message bus](/docs/mocha/v16/handler-registration). | | **Command** | A mediator message representing an action. Implements `ICommand` (void) or `ICommand` (with response). Dispatched via `SendAsync`. | | **Query** | A mediator message representing a read operation. Implements `IQuery`. Dispatched via `QueryAsync`. | @@ -157,7 +157,7 @@ Sagas coordinate multi-step workflows that span multiple services and messages. -Mocha persists saga state, manages transitions, and supports compensation when steps fail. See [Sagas](/docs/mocha/v1/sagas) for a full walkthrough. +Mocha persists saga state, manages transitions, and supports compensation when steps fail. See [Sagas](/docs/mocha/v16/sagas) for a full walkthrough. ## In-process mediator @@ -191,17 +191,17 @@ app.MapPost("/orders", async (ISender sender) => await sender.SendAsync(new PlaceOrderCommand(productId, 2))); ``` -The mediator supports commands (with and without responses), queries, notifications, middleware, and EF Core transaction wrapping (commands only by default, configurable via delegate). The source generator produces a typed registration method per assembly (e.g. `AddCatalog()`) that wires up all handlers and pre-compiled dispatch pipelines automatically. See [Mediator](/docs/mocha/v1/mediator) for the full guide. +The mediator supports commands (with and without responses), queries, notifications, middleware, and EF Core transaction wrapping (commands only by default, configurable via delegate). The source generator produces a typed registration method per assembly (e.g. `AddCatalog()`) that wires up all handlers and pre-compiled dispatch pipelines automatically. See [Mediator](/docs/mocha/v16/mediator) for the full guide. # Learning paths Choose an entry point based on how you learn best: -- **Get something running first:** [Quick Start](/docs/mocha/v1/quick-start) -zero to a working message bus in under five minutes with the InMemory transport. -- **Understand the concepts first:** [Messages](/docs/mocha/v1/messages) then [Messaging Patterns](/docs/mocha/v1/messaging-patterns) - learn what flows through the system and what patterns govern how it flows. -- **Evaluating Mocha for a specific broker:** [Transports](/docs/mocha/v1/transports) - understand the transport abstraction and what is available. -- **In-process CQRS:** [Mediator](/docs/mocha/v1/mediator) - dispatch commands, queries, and notifications within a single service using the source-generated mediator. +- **Get something running first:** [Quick Start](/docs/mocha/v16/quick-start) -zero to a working message bus in under five minutes with the InMemory transport. +- **Understand the concepts first:** [Messages](/docs/mocha/v16/messages) then [Messaging Patterns](/docs/mocha/v16/messaging-patterns) - learn what flows through the system and what patterns govern how it flows. +- **Evaluating Mocha for a specific broker:** [Transports](/docs/mocha/v16/transports) - understand the transport abstraction and what is available. +- **In-process CQRS:** [Mediator](/docs/mocha/v16/mediator) - dispatch commands, queries, and notifications within a single service using the source-generated mediator. - **See a real-world system:** The [Demo application](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/examples/Demo) is a complete e-commerce system with three services (Catalog, Billing, Shipping) that demonstrates event-driven communication, sagas, batch processing, the transactional outbox, and .NET Aspire orchestration. -Ready to build? Start with the [Quick Start](/docs/mocha/v1/quick-start). +Ready to build? Start with the [Quick Start](/docs/mocha/v16/quick-start). diff --git a/website/src/docs/mocha/v1/mediator/index.md b/website/src/docs/mocha/v16/mediator/index.md similarity index 99% rename from website/src/docs/mocha/v1/mediator/index.md rename to website/src/docs/mocha/v16/mediator/index.md index 12208631f89..9e420638dfd 100644 --- a/website/src/docs/mocha/v1/mediator/index.md +++ b/website/src/docs/mocha/v16/mediator/index.md @@ -491,4 +491,4 @@ Each named mediator resolves handlers from the same DI container. Make sure you You have a working mediator with CQRS dispatch. Here is where to go next: -- **Customize the pipeline:** [Pipeline & Middleware](/docs/mocha/v1/mediator/pipeline-and-middleware) - add validation, logging, transactions, and other cross-cutting concerns. Configure notification publish modes and OpenTelemetry instrumentation. +- **Customize the pipeline:** [Pipeline & Middleware](/docs/mocha/v16/mediator/pipeline-and-middleware) - add validation, logging, transactions, and other cross-cutting concerns. Configure notification publish modes and OpenTelemetry instrumentation. diff --git a/website/src/docs/mocha/v1/mediator/pipeline-and-middleware.md b/website/src/docs/mocha/v16/mediator/pipeline-and-middleware.md similarity index 98% rename from website/src/docs/mocha/v1/mediator/pipeline-and-middleware.md rename to website/src/docs/mocha/v16/mediator/pipeline-and-middleware.md index e45a53b68da..a515cdee82a 100644 --- a/website/src/docs/mocha/v1/mediator/pipeline-and-middleware.md +++ b/website/src/docs/mocha/v16/mediator/pipeline-and-middleware.md @@ -592,7 +592,7 @@ When using `NotificationPublishMode.Concurrent`, all handler pipelines execute i # Next steps -- **Mediator overview:** [Overview](/docs/mocha/v1/mediator) - messages, handlers, dispatching, and registration. -- **Message bus middleware:** [Middleware & Pipelines](/docs/mocha/v1/middleware-and-pipelines) - the message bus has its own three-layer pipeline (dispatch, receive, consume) using the same middleware model. -- **Cross service boundaries:** [Messaging Patterns](/docs/mocha/v1/messaging-patterns) - when your commands need to reach another service, switch to the message bus. -- **Coordinate workflows:** [Sagas](/docs/mocha/v1/sagas) - orchestrate multi-step processes across services. +- **Mediator overview:** [Overview](/docs/mocha/v16/mediator) - messages, handlers, dispatching, and registration. +- **Message bus middleware:** [Middleware & Pipelines](/docs/mocha/v16/middleware-and-pipelines) - the message bus has its own three-layer pipeline (dispatch, receive, consume) using the same middleware model. +- **Cross service boundaries:** [Messaging Patterns](/docs/mocha/v16/messaging-patterns) - when your commands need to reach another service, switch to the message bus. +- **Coordinate workflows:** [Sagas](/docs/mocha/v16/sagas) - orchestrate multi-step processes across services. diff --git a/website/src/docs/mocha/v1/messages.md b/website/src/docs/mocha/v16/messages.md similarity index 98% rename from website/src/docs/mocha/v1/messages.md rename to website/src/docs/mocha/v16/messages.md index 0e13a3ae7d4..b9bb348a77d 100644 --- a/website/src/docs/mocha/v1/messages.md +++ b/website/src/docs/mocha/v16/messages.md @@ -202,6 +202,6 @@ When you need to refactor a message type's CLR namespace without changing its wi Now that you understand message structure, learn the three messaging patterns. -- [**Messaging Patterns**](/docs/mocha/v1/messaging-patterns) - Pub/sub events, point-to-point commands, and request/reply. +- [**Messaging Patterns**](/docs/mocha/v16/messaging-patterns) - Pub/sub events, point-to-point commands, and request/reply. > **Full demo:** [Demo.Contracts](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/examples/Demo/Demo.Contracts) contains a complete set of message contracts for an e-commerce system - events (`OrderPlacedEvent`, `PaymentCompletedEvent`), send messages (`ProcessRefundCommand`, `ReserveInventoryCommand`), and request/reply pairs used by sagas. diff --git a/website/src/docs/mocha/v1/messaging-patterns.md b/website/src/docs/mocha/v16/messaging-patterns.md similarity index 99% rename from website/src/docs/mocha/v1/messaging-patterns.md rename to website/src/docs/mocha/v16/messaging-patterns.md index 69969ea7d9c..762023b478f 100644 --- a/website/src/docs/mocha/v1/messaging-patterns.md +++ b/website/src/docs/mocha/v16/messaging-patterns.md @@ -473,4 +473,4 @@ If your request record does not implement `IEventRequest`, you cannot > > **Full demo:** The [Demo application](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/examples/Demo) uses all three patterns: [Demo.Catalog](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/examples/Demo/Demo.Catalog) publishes `OrderPlacedEvent` (pub/sub), [Demo.Billing](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/examples/Demo/Demo.Billing) handles `ProcessRefundCommand` (send), and sagas use `RequestAsync` for request/reply coordination. -Ready to implement these patterns? See [Handlers and Consumers](/docs/mocha/v1/handlers-and-consumers). +Ready to implement these patterns? See [Handlers and Consumers](/docs/mocha/v16/handlers-and-consumers). diff --git a/website/src/docs/mocha/v1/middleware-and-pipelines.md b/website/src/docs/mocha/v16/middleware-and-pipelines.md similarity index 86% rename from website/src/docs/mocha/v1/middleware-and-pipelines.md rename to website/src/docs/mocha/v16/middleware-and-pipelines.md index fe4dec9015c..7687d48430d 100644 --- a/website/src/docs/mocha/v1/middleware-and-pipelines.md +++ b/website/src/docs/mocha/v16/middleware-and-pipelines.md @@ -286,34 +286,34 @@ The factory lambda in `ReceiveMiddlewareConfiguration`, `ConsumerMiddlewareConfi Each pipeline type has a single registration method with optional `before` and `after` parameters: -| Method | Pipeline | Behavior | -| --------------------------------------------------- | -------- | ----------------------------------------------- | -| `UseReceive(config)` | Receive | Append to the pipeline | -| `UseReceive(config, before: "key")` | Receive | Insert before the middleware with the given key | -| `UseReceive(config, after: "key")` | Receive | Insert after the middleware with the given key | -| `UseDispatch(config)` | Dispatch | Append to the pipeline | -| `UseDispatch(config, before: "key")` | Dispatch | Insert before the middleware with the given key | -| `UseDispatch(config, after: "key")` | Dispatch | Insert after the middleware with the given key | -| `UseConsume(config)` | Consumer | Append to the pipeline | -| `UseConsume(config, before: "key")` | Consumer | Insert before the middleware with the given key | -| `UseConsume(config, after: "key")` | Consumer | Insert after the middleware with the given key | +| Method | Pipeline | Behavior | +| ------------------------------------ | -------- | ----------------------------------------------- | +| `UseReceive(config)` | Receive | Append to the pipeline | +| `UseReceive(config, before: "key")` | Receive | Insert before the middleware with the given key | +| `UseReceive(config, after: "key")` | Receive | Insert after the middleware with the given key | +| `UseDispatch(config)` | Dispatch | Append to the pipeline | +| `UseDispatch(config, before: "key")` | Dispatch | Insert before the middleware with the given key | +| `UseDispatch(config, after: "key")` | Dispatch | Insert after the middleware with the given key | +| `UseConsume(config)` | Consumer | Append to the pipeline | +| `UseConsume(config, before: "key")` | Consumer | Insert before the middleware with the given key | +| `UseConsume(config, after: "key")` | Consumer | Insert after the middleware with the given key | Only one of `before` or `after` can be specified at the same time. If neither is specified, the middleware is appended after the built-in defaults. Middleware is compiled once at startup into a single delegate chain. Register all middleware during bus configuration, before the service provider is built. Middleware added after the bus starts has no effect. -Middleware can also be registered at transport or endpoint scope. Bus-level middleware applies to all transports and endpoints. Transport-level middleware applies to all endpoints on that transport. Endpoint-level middleware applies to a single endpoint. The most specific scope wins. This is the same scope hierarchy described in [Routing and Endpoints](/docs/mocha/v1/routing-and-endpoints). +Middleware can also be registered at transport or endpoint scope. Bus-level middleware applies to all transports and endpoints. Transport-level middleware applies to all endpoints on that transport. Endpoint-level middleware applies to a single endpoint. The most specific scope wins. This is the same scope hierarchy described in [Routing and Endpoints](/docs/mocha/v16/routing-and-endpoints). # Built-in middleware and feature pages The built-in middleware in the receive pipeline implements the reliability and observability features described on their own pages: -- The `Inbox` middleware deduplicates incoming messages based on `MessageId`, described in [Reliability](/docs/mocha/v1/reliability#deduplicate-messages-with-the-transactional-inbox). It runs in the **consumer pipeline** after the transaction middleware so that the inbox claim participates in the same database transaction as the handler's business data. Use `UseConsume(config, before: "Inbox")` or `UseConsume(config, after: "Inbox")` to position your middleware relative to it. -- The `CircuitBreaker` and `DeadLetter` middleware implement the circuit breaker and dead-letter behaviors described in [Reliability](/docs/mocha/v1/reliability). Use `UseReceive(config, before: "key")` or `UseReceive(config, after: "key")` with their keys to position your middleware relative to them. -- The `ReceiveInstrumentation` middleware generates the OpenTelemetry spans and metrics described in [Observability](/docs/mocha/v1/observability). Place logging or correlation middleware after `ReceiveInstrumentation` using `UseReceive(config, after: "ReceiveInstrumentation")`. +- The `Inbox` middleware deduplicates incoming messages based on `MessageId`, described in [Reliability](/docs/mocha/v16/reliability#deduplicate-messages-with-the-transactional-inbox). It runs in the **consumer pipeline** after the transaction middleware so that the inbox claim participates in the same database transaction as the handler's business data. Use `UseConsume(config, before: "Inbox")` or `UseConsume(config, after: "Inbox")` to position your middleware relative to it. +- The `CircuitBreaker` and `DeadLetter` middleware implement the circuit breaker and dead-letter behaviors described in [Reliability](/docs/mocha/v16/reliability). Use `UseReceive(config, before: "key")` or `UseReceive(config, after: "key")` with their keys to position your middleware relative to them. +- The `ReceiveInstrumentation` middleware generates the OpenTelemetry spans and metrics described in [Observability](/docs/mocha/v16/observability). Place logging or correlation middleware after `ReceiveInstrumentation` using `UseReceive(config, after: "ReceiveInstrumentation")`. # Next steps -The pipeline handles failures automatically. Learn how circuit breaking, dead-letter routing, the transactional outbox, and the idempotent inbox work in [Reliability](/docs/mocha/v1/reliability). +The pipeline handles failures automatically. Learn how circuit breaking, dead-letter routing, the transactional outbox, and the idempotent inbox work in [Reliability](/docs/mocha/v16/reliability). > **Runnable examples:** [CustomMiddleware](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/Middleware/CustomMiddleware), [UnitOfWork](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/Middleware/UnitOfWork) diff --git a/website/src/docs/mocha/v1/observability.md b/website/src/docs/mocha/v16/observability.md similarity index 94% rename from website/src/docs/mocha/v1/observability.md rename to website/src/docs/mocha/v16/observability.md index 5bfe64a8e7e..d154cd92d76 100644 --- a/website/src/docs/mocha/v1/observability.md +++ b/website/src/docs/mocha/v16/observability.md @@ -79,7 +79,7 @@ sequenceDiagram B->>B: consumer span (Consumer) ``` -Tracing and metrics are injected by middleware in all three pipelines: `DispatchInstrumentation`, `ReceiveInstrumentation`, and `ConsumerInstrumentation`. See [Middleware and Pipelines](/docs/mocha/v1/middleware-and-pipelines) for how these fit into the pipeline architecture and how to reorder or replace them. +Tracing and metrics are injected by middleware in all three pipelines: `DispatchInstrumentation`, `ReceiveInstrumentation`, and `ConsumerInstrumentation`. See [Middleware and Pipelines](/docs/mocha/v16/middleware-and-pipelines) for how these fit into the pipeline architecture and how to reorder or replace them. # How to implement a custom diagnostic observer @@ -199,9 +199,9 @@ For more detail on .NET distributed tracing concepts and how `Activity` maps to # Next steps -- [Middleware and Pipelines](/docs/mocha/v1/middleware-and-pipelines) - Understand how `DispatchInstrumentation`, `ReceiveInstrumentation`, and `ConsumerInstrumentation` fit into each pipeline. -- [Reliability](/docs/mocha/v1/reliability) - Configure fault handling and circuit breakers that work alongside observability. -- [Sagas](/docs/mocha/v1/sagas) - For long-running workflows that span multiple messages, see Sagas. +- [Middleware and Pipelines](/docs/mocha/v16/middleware-and-pipelines) - Understand how `DispatchInstrumentation`, `ReceiveInstrumentation`, and `ConsumerInstrumentation` fit into each pipeline. +- [Reliability](/docs/mocha/v16/reliability) - Configure fault handling and circuit breakers that work alongside observability. +- [Sagas](/docs/mocha/v16/sagas) - For long-running workflows that span multiple messages, see Sagas. > **Runnable example:** [OpenTelemetry](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/Observability/OpenTelemetry) > diff --git a/website/src/docs/mocha/v1/quick-start.md b/website/src/docs/mocha/v16/quick-start.md similarity index 94% rename from website/src/docs/mocha/v1/quick-start.md rename to website/src/docs/mocha/v16/quick-start.md index f9e72a7c9bd..02a47ea0f55 100644 --- a/website/src/docs/mocha/v1/quick-start.md +++ b/website/src/docs/mocha/v16/quick-start.md @@ -111,7 +111,7 @@ app.Run(); Each registration line has a single responsibility: - `AddMessageBus()` - registers the bus runtime and core services into DI. -- `AddMochaQuickStart()` - source-generated method that discovers and registers all handlers in this assembly. Named after the project - to customize the name, see [Handler Registration](/docs/mocha/v1/handler-registration). +- `AddMochaQuickStart()` - source-generated method that discovers and registers all handlers in this assembly. Named after the project - to customize the name, see [Handler Registration](/docs/mocha/v16/handler-registration). - `AddInMemory()` - adds the InMemory transport; messages stay in-process. # Publish and verify @@ -151,11 +151,11 @@ Your POST request hit the `/orders` endpoint, which called `PublishAsync` on `IM You have a working message bus. Here is where to go next: -- **Understand messages:** [Messages](/docs/mocha/v1/messages) - learn what a message is, how the envelope wraps it, and naming conventions for events and commands. -- **Learn the three patterns:** [Messaging Patterns](/docs/mocha/v1/messaging-patterns) - understand when to use pub/sub events, commands, and request/reply. -- **Move to production:** [Transports](/docs/mocha/v1/transports) - switch from InMemory to RabbitMQ for real workloads. +- **Understand messages:** [Messages](/docs/mocha/v16/messages) - learn what a message is, how the envelope wraps it, and naming conventions for events and commands. +- **Learn the three patterns:** [Messaging Patterns](/docs/mocha/v16/messaging-patterns) - understand when to use pub/sub events, commands, and request/reply. +- **Move to production:** [Transports](/docs/mocha/v16/transports) - switch from InMemory to RabbitMQ for real workloads. -Now that you have a working app, learn how messages work in [Messages](/docs/mocha/v1/messages). +Now that you have a working app, learn how messages work in [Messages](/docs/mocha/v16/messages). > **Runnable example:** [Examples/QuickStart](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/QuickStart) > diff --git a/website/src/docs/mocha/v1/reliability.md b/website/src/docs/mocha/v16/reliability.md similarity index 95% rename from website/src/docs/mocha/v1/reliability.md rename to website/src/docs/mocha/v16/reliability.md index 0d0fb6d24fa..4ba04f65d19 100644 --- a/website/src/docs/mocha/v1/reliability.md +++ b/website/src/docs/mocha/v16/reliability.md @@ -85,7 +85,7 @@ When your handler throws an exception, Mocha's fault middleware catches it and t The fault middleware marks the message as consumed after handling, which prevents the dead-letter middleware from re-forwarding it. -The fault handler is implemented as the `Fault` middleware in the receive pipeline. See [Middleware and Pipelines](/docs/mocha/v1/middleware-and-pipelines) for positioning and customization. +The fault handler is implemented as the `Fault` middleware in the receive pipeline. See [Middleware and Pipelines](/docs/mocha/v16/middleware-and-pipelines) for positioning and customization. ## Verify fault behavior @@ -238,11 +238,11 @@ builder.Services Exception matching respects inheritance. `On()` also matches `NpgsqlException` and any other `DbException` subclass. When multiple rules match, the most specific type wins - the same precedence as C# `catch` blocks. -For the full API including predicates, conditional policies, and escalation chains, see [Exception Policies](/docs/mocha/v1/exception-policies). +For the full API including predicates, conditional policies, and escalation chains, see [Exception Policies](/docs/mocha/v16/exception-policies). ## Override retry per consumer -The bus-level exception policy applies to all consumers. Override it for specific consumers that need different behavior. See [Handlers and Consumers](/docs/mocha/v1/handlers-and-consumers) for the full consumer configuration API. +The bus-level exception policy applies to all consumers. Override it for specific consumers that need different behavior. See [Handlers and Consumers](/docs/mocha/v16/handlers-and-consumers) for the full consumer configuration API. ```csharp builder.Services @@ -298,7 +298,7 @@ Redelivery lives in the **receive pipeline**, not the consumer pipeline. This ma 1. **Single decision point.** When an endpoint has multiple consumers, you want one redelivery decision per message, not one per consumer. 2. **Releases the concurrency slot.** Retry holds the slot while waiting. Redelivery returns the message to the transport and frees the slot for other messages. -Redelivery uses Mocha's [scheduling infrastructure](/docs/mocha/v1/scheduling) to schedule the message for future delivery. The message re-enters the full receive pipeline when it arrives - fresh routing, fresh consumer invocations, fresh retry attempts. +Redelivery uses Mocha's [scheduling infrastructure](/docs/mocha/v16/scheduling) to schedule the message for future delivery. The message re-enters the full receive pipeline when it arrives - fresh routing, fresh consumer invocations, fresh retry attempts. ```text Receive pipeline: @@ -525,7 +525,7 @@ public class PaymentConsumer(ILogger logger) : IConsumer **Runnable examples:** [OutboxInbox](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/Reliability/OutboxInbox), [CircuitBreaker](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/Reliability/CircuitBreaker) > diff --git a/website/src/docs/mocha/v1/routing-and-endpoints.md b/website/src/docs/mocha/v16/routing-and-endpoints.md similarity index 96% rename from website/src/docs/mocha/v1/routing-and-endpoints.md rename to website/src/docs/mocha/v16/routing-and-endpoints.md index 6041bd4ed0b..9a81b714aa9 100644 --- a/website/src/docs/mocha/v1/routing-and-endpoints.md +++ b/website/src/docs/mocha/v16/routing-and-endpoints.md @@ -282,7 +282,7 @@ builder.Services }); ``` -This approach sits between implicit and explicit binding: you keep automatic endpoint naming but gain per-handler configuration. See the [RabbitMQ](/docs/mocha/v1/transports/rabbitmq), [PostgreSQL](/docs/mocha/v1/transports/postgres), and [InMemory](/docs/mocha/v1/transports/in-memory) transport pages for the full set of transport-specific endpoint settings. +This approach sits between implicit and explicit binding: you keep automatic endpoint naming but gain per-handler configuration. See the [RabbitMQ](/docs/mocha/v16/transports/rabbitmq), [PostgreSQL](/docs/mocha/v16/transports/postgres), and [InMemory](/docs/mocha/v16/transports/in-memory) transport pages for the full set of transport-specific endpoint settings. ## Explicit binding @@ -407,6 +407,6 @@ The middleware pipeline is compiled per-endpoint from the same three layers: bus Your routing and endpoint configuration is set. From here: -- [**Middleware and Pipelines**](/docs/mocha/v1/middleware-and-pipelines) - Write custom middleware, control pipeline ordering, and understand how the three pipeline stages interact. Want to customize the processing pipeline? That's the next page. -- [**Reliability**](/docs/mocha/v1/reliability) - Configure fault handling, circuit breakers, concurrency limits, the transactional outbox, and the idempotent inbox. -- [**Transports**](/docs/mocha/v1/transports) - Dive into transport-specific configuration for RabbitMQ and InMemory. +- [**Middleware and Pipelines**](/docs/mocha/v16/middleware-and-pipelines) - Write custom middleware, control pipeline ordering, and understand how the three pipeline stages interact. Want to customize the processing pipeline? That's the next page. +- [**Reliability**](/docs/mocha/v16/reliability) - Configure fault handling, circuit breakers, concurrency limits, the transactional outbox, and the idempotent inbox. +- [**Transports**](/docs/mocha/v16/transports) - Dive into transport-specific configuration for RabbitMQ and InMemory. diff --git a/website/src/docs/mocha/v1/sagas.md b/website/src/docs/mocha/v16/sagas.md similarity index 97% rename from website/src/docs/mocha/v1/sagas.md rename to website/src/docs/mocha/v16/sagas.md index 73a5721558d..938355d5453 100644 --- a/website/src/docs/mocha/v1/sagas.md +++ b/website/src/docs/mocha/v16/sagas.md @@ -224,7 +224,7 @@ app.Run(); `.AddSaga()` registers the saga with the bus. The saga's consumer is created automatically and listens for the message types defined in the state machine transitions. -> **Tip:** Sagas are discovered automatically by the source generator. If you use `Add{ModuleName}()` from [Handler Registration](/docs/mocha/v1/handler-registration), you do not need to register sagas manually - the source generator calls `AddSaga()` for every concrete `Saga` subclass it finds. +> **Tip:** Sagas are discovered automatically by the source generator. If you use `Add{ModuleName}()` from [Handler Registration](/docs/mocha/v16/handler-registration), you do not need to register sagas manually - the source generator calls `AddSaga()` for every concrete `Saga` subclass it finds. ## Trigger the saga @@ -623,7 +623,7 @@ A saga that waits for a message that never arrives will stay in its current stat Mocha provides a saga-level `Timeout()` API that sets a single deadline for the entire saga instance. The timeout is scheduled when the saga is created and automatically cancelled when the saga reaches any final state. -> **Prerequisites:** Durable, cancellable timeouts require a scheduling store. Configure `UsePostgresScheduling()` before using `Timeout()` — see [Scheduling: Set up store-based scheduling](/docs/mocha/v1/scheduling#set-up-store-based-scheduling-for-rabbitmq) for setup instructions. Native transport scheduling (InMemory, PostgreSQL) also works but does not support automatic cancellation. +> **Prerequisites:** Durable, cancellable timeouts require a scheduling store. Configure `UsePostgresScheduling()` before using `Timeout()` — see [Scheduling: Set up store-based scheduling](/docs/mocha/v16/scheduling#set-up-store-based-scheduling-for-rabbitmq) for setup instructions. Native transport scheduling (InMemory, PostgreSQL) also works but does not support automatic cancellation. ## Configure a saga-level timeout @@ -666,16 +666,16 @@ Use `OnTimeout()` on a state descriptor to define what happens when the timeout ## Key behaviors -| Behavior | Detail | -| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Scope | Per-saga instance, not per-state. The deadline covers the entire saga lifetime. | -| Duration | Fixed at configuration time via `TimeSpan`. | -| Auto-cancellation | When the saga reaches any final state (normal completion, error final state, etc.), the pending timeout is cancelled. | -| Late delivery | If the timeout fires after the saga was already deleted, the event is silently dropped. | -| Missing handler | If no `OnTimeout()` handler is configured for the current state, the saga throws an execution error. See [troubleshooting](#timeout-troubleshooting) below. | -| Recommended pattern | `DuringAny().OnTimeout()` handles the timeout regardless of which state the saga is in. | -| Response on timeout | Chain `.Respond()` on the timed-out final state to send a response back to the original requester. | -| Scheduling store | Requires a scheduling store for durable timeouts. Configure `UsePostgresScheduling()` — see [Scheduling](/docs/mocha/v1/scheduling#set-up-store-based-scheduling-for-rabbitmq) for setup. Native transport scheduling (InMemory, PostgreSQL) also works but does not support cancellation. | +| Behavior | Detail | +| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Scope | Per-saga instance, not per-state. The deadline covers the entire saga lifetime. | +| Duration | Fixed at configuration time via `TimeSpan`. | +| Auto-cancellation | When the saga reaches any final state (normal completion, error final state, etc.), the pending timeout is cancelled. | +| Late delivery | If the timeout fires after the saga was already deleted, the event is silently dropped. | +| Missing handler | If no `OnTimeout()` handler is configured for the current state, the saga throws an execution error. See [troubleshooting](#timeout-troubleshooting) below. | +| Recommended pattern | `DuringAny().OnTimeout()` handles the timeout regardless of which state the saga is in. | +| Response on timeout | Chain `.Respond()` on the timed-out final state to send a response back to the original requester. | +| Scheduling store | Requires a scheduling store for durable timeouts. Configure `UsePostgresScheduling()` — see [Scheduling](/docs/mocha/v16/scheduling#set-up-store-based-scheduling-for-rabbitmq) for setup. Native transport scheduling (InMemory, PostgreSQL) also works but does not support cancellation. | ## Timeout troubleshooting @@ -752,7 +752,7 @@ The Postgres saga store uses optimistic concurrency. The second writer detects t # Next steps -Understand how transports work in [Transports](/docs/mocha/v1/transports). +Understand how transports work in [Transports](/docs/mocha/v16/transports). > **Runnable examples:** [BasicSaga](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/Sagas/BasicSaga), [ParallelSaga](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/Sagas/ParallelSaga) > diff --git a/website/src/docs/mocha/v1/scheduling.md b/website/src/docs/mocha/v16/scheduling.md similarity index 94% rename from website/src/docs/mocha/v1/scheduling.md rename to website/src/docs/mocha/v16/scheduling.md index 06806c6aba1..10f6e8c24a7 100644 --- a/website/src/docs/mocha/v1/scheduling.md +++ b/website/src/docs/mocha/v16/scheduling.md @@ -238,7 +238,7 @@ Each transport handles scheduling differently. Mocha adapts automatically based **InMemory:** The transport schedules messages natively using an internal scheduler. Messages scheduled for a time in the past are delivered immediately. Scheduled messages are lost if the process restarts. Cancellation is not supported. -**PostgreSQL:** The transport handles scheduling natively. When you set `ScheduledTime`, the transport writes a `scheduled_time` column alongside the message. Messages are only delivered to consumers after the scheduled time has passed. No additional setup is required beyond the standard [PostgreSQL transport configuration](/docs/mocha/v1/transports/postgres). Cancellation is not supported with native scheduling. +**PostgreSQL:** The transport handles scheduling natively. When you set `ScheduledTime`, the transport writes a `scheduled_time` column alongside the message. Messages are only delivered to consumers after the scheduled time has passed. No additional setup is required beyond the standard [PostgreSQL transport configuration](/docs/mocha/v16/transports/postgres). Cancellation is not supported with native scheduling. **RabbitMQ:** RabbitMQ does not support native message scheduling. To enable scheduling, register `UsePostgresScheduling()` with an EF Core DbContext. Scheduled messages are intercepted before they reach the RabbitMQ transport and persisted to a Postgres `scheduled_messages` table. A background worker dispatches them at the scheduled time, routing through the RabbitMQ transport. Cancellation is fully supported - the `SchedulingResult` contains a token you can use with `CancelScheduledMessageAsync`. @@ -252,7 +252,7 @@ When multiple instances of your service are running, each scheduled message is p ## Outbox integration -When both the transactional outbox and scheduling are configured, scheduled messages participate in the transaction correctly. Messages with a `ScheduledTime` are intercepted by the scheduler and never reach the outbox. Messages dispatched by the background worker skip both the scheduler and the outbox, going directly to the transport. See [Reliability](/docs/mocha/v1/reliability) for outbox configuration. +When both the transactional outbox and scheduling are configured, scheduled messages participate in the transaction correctly. Messages with a `ScheduledTime` are intercepted by the scheduler and never reach the outbox. Messages dispatched by the background worker skip both the scheduler and the outbox, going directly to the transport. See [Reliability](/docs/mocha/v16/reliability) for outbox configuration. # Schedule messages in sagas @@ -296,9 +296,9 @@ x.WhenCompleted() Both `ScheduledPublish` and `ScheduledSend` are available on `ISagaTransitionDescriptor` and `ISagaLifeCycleDescriptor`. The factory receives the current saga state and returns the message to schedule. -For automatic saga timeouts that cancel themselves on completion, see [Timeouts](/docs/mocha/v1/sagas#timeouts) in the Sagas guide. +For automatic saga timeouts that cancel themselves on completion, see [Timeouts](/docs/mocha/v16/sagas#timeouts) in the Sagas guide. -See [Sagas](/docs/mocha/v1/sagas) for the full saga configuration guide. +See [Sagas](/docs/mocha/v16/sagas) for the full saga configuration guide. # Troubleshooting @@ -331,7 +331,7 @@ No store-based scheduling provider is registered. Cancellation requires a provid # Next steps -- [**Reliability**](/docs/mocha/v1/reliability) - Configure the transactional outbox and inbox for guaranteed delivery alongside scheduling. -- [**Sagas**](/docs/mocha/v1/sagas) - Build multi-step workflows with state machines, timeouts, and scheduled side effects. -- [**PostgreSQL Transport**](/docs/mocha/v1/transports/postgres) - Set up the Postgres transport that powers durable scheduling. -- [**Messaging Patterns**](/docs/mocha/v1/messaging-patterns) - Understand the difference between publish (fan-out) and send (point-to-point) when choosing which scheduling method to use. +- [**Reliability**](/docs/mocha/v16/reliability) - Configure the transactional outbox and inbox for guaranteed delivery alongside scheduling. +- [**Sagas**](/docs/mocha/v16/sagas) - Build multi-step workflows with state machines, timeouts, and scheduled side effects. +- [**PostgreSQL Transport**](/docs/mocha/v16/transports/postgres) - Set up the Postgres transport that powers durable scheduling. +- [**Messaging Patterns**](/docs/mocha/v16/messaging-patterns) - Understand the difference between publish (fan-out) and send (point-to-point) when choosing which scheduling method to use. diff --git a/website/src/docs/mocha/v1/transports/in-memory.md b/website/src/docs/mocha/v16/transports/in-memory.md similarity index 96% rename from website/src/docs/mocha/v1/transports/in-memory.md rename to website/src/docs/mocha/v16/transports/in-memory.md index 37b8c2e47fb..a10ae2fbd94 100644 --- a/website/src/docs/mocha/v1/transports/in-memory.md +++ b/website/src/docs/mocha/v16/transports/in-memory.md @@ -152,5 +152,5 @@ builder.Services # Next steps -- [RabbitMQ Transport](/docs/mocha/v1/transports/rabbitmq) - Configure the RabbitMQ transport for production deployments. -- [Handlers and Consumers](/docs/mocha/v1/handlers-and-consumers) - Learn about every handler type and how to register them. +- [RabbitMQ Transport](/docs/mocha/v16/transports/rabbitmq) - Configure the RabbitMQ transport for production deployments. +- [Handlers and Consumers](/docs/mocha/v16/handlers-and-consumers) - Learn about every handler type and how to register them. diff --git a/website/src/docs/mocha/v1/transports/index.md b/website/src/docs/mocha/v16/transports/index.md similarity index 97% rename from website/src/docs/mocha/v1/transports/index.md rename to website/src/docs/mocha/v16/transports/index.md index 0de535c20f8..1e328188d89 100644 --- a/website/src/docs/mocha/v1/transports/index.md +++ b/website/src/docs/mocha/v16/transports/index.md @@ -183,7 +183,7 @@ Each transport manages its own connections, topology, and middleware pipeline in # Next steps -- [InMemory Transport](/docs/mocha/v1/transports/in-memory) - Set up the InMemory transport for development and testing. -- [RabbitMQ Transport](/docs/mocha/v1/transports/rabbitmq) - Configure the RabbitMQ transport for production deployments. +- [InMemory Transport](/docs/mocha/v16/transports/in-memory) - Set up the InMemory transport for development and testing. +- [RabbitMQ Transport](/docs/mocha/v16/transports/rabbitmq) - Configure the RabbitMQ transport for production deployments. > **Runnable example:** [MultiTransport](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/Transports/MultiTransport) diff --git a/website/src/docs/mocha/v1/transports/postgres.md b/website/src/docs/mocha/v16/transports/postgres.md similarity index 97% rename from website/src/docs/mocha/v1/transports/postgres.md rename to website/src/docs/mocha/v16/transports/postgres.md index af30623bf26..b15114b052a 100644 --- a/website/src/docs/mocha/v1/transports/postgres.md +++ b/website/src/docs/mocha/v16/transports/postgres.md @@ -439,11 +439,11 @@ All auto-provisioned resources are inserted as rows in the corresponding topolog # Next steps -- [Transports Overview](/docs/mocha/v1/transports) - Understand the transport abstraction and lifecycle. -- [Handlers and Consumers](/docs/mocha/v1/handlers-and-consumers) - Learn about handler types and consumer configuration. -- [Reliability](/docs/mocha/v1/reliability) - Configure dead-letter routing, outbox, inbox, and fault handling. -- [Middleware and Pipelines](/docs/mocha/v1/middleware-and-pipelines) - Customize the receive and dispatch pipelines. -- [Routing and Endpoints](/docs/mocha/v1/routing-and-endpoints) - Understand naming conventions and endpoint model. +- [Transports Overview](/docs/mocha/v16/transports) - Understand the transport abstraction and lifecycle. +- [Handlers and Consumers](/docs/mocha/v16/handlers-and-consumers) - Learn about handler types and consumer configuration. +- [Reliability](/docs/mocha/v16/reliability) - Configure dead-letter routing, outbox, inbox, and fault handling. +- [Middleware and Pipelines](/docs/mocha/v16/middleware-and-pipelines) - Customize the receive and dispatch pipelines. +- [Routing and Endpoints](/docs/mocha/v16/routing-and-endpoints) - Understand naming conventions and endpoint model. > **Runnable example:** [PostgresTransport](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/PostgresTransport) > diff --git a/website/src/docs/mocha/v1/transports/rabbitmq.md b/website/src/docs/mocha/v16/transports/rabbitmq.md similarity index 98% rename from website/src/docs/mocha/v1/transports/rabbitmq.md rename to website/src/docs/mocha/v16/transports/rabbitmq.md index b50c715a1ff..f054ce9d7b3 100644 --- a/website/src/docs/mocha/v1/transports/rabbitmq.md +++ b/website/src/docs/mocha/v16/transports/rabbitmq.md @@ -609,9 +609,9 @@ Messages with `Priority = "high"` reach the queue. Messages with any other prior # Next steps -- [Transports Overview](/docs/mocha/v1/transports) - Understand the transport abstraction and lifecycle. -- [Handlers and Consumers](/docs/mocha/v1/handlers-and-consumers) - Learn about handler types and consumer configuration. -- [Reliability](/docs/mocha/v1/reliability) - Configure dead-letter routing, outbox, inbox, and fault handling. +- [Transports Overview](/docs/mocha/v16/transports) - Understand the transport abstraction and lifecycle. +- [Handlers and Consumers](/docs/mocha/v16/handlers-and-consumers) - Learn about handler types and consumer configuration. +- [Reliability](/docs/mocha/v16/reliability) - Configure dead-letter routing, outbox, inbox, and fault handling. > **Runnable example:** [RabbitMQ](https://github.com/ChilliCream/graphql-platform/tree/main/src/Mocha/src/Examples/Transports/RabbitMQ) >