Summary

Adds Projections, that are a special type of event handler dealing with read models. Each Projection deals with one read model and mutates it's properties. The read models are saved into the Runtime's projection store. Any changes to the Projection causes it to be fully replayed.

Added

• Grpc service for getting projections
• REST (WebAPI) service for getting projections
• Grpc service for registering and processing projections
• A MongoDB store for projections - stores the definitions in projection-definitions and the projections in projection-projectionid collections. It's defined in the resources.json:

"projections": {
    "servers": [
        "localhost"
    ],
    "database": "projections",
    "maxConnectionPoolSize": 1000
}

Changed

• Adhere to latest protobuf contracts

Summary

Updates and adheres to new contracts

Changed

• TryGetAll states now returns an enumerable of a tuple of the state and the key
• Adhere to new contracts

Summary

Better enum conversion

Changed

• Change how some enums are converted between protobuf and runtime representation

Summary

Adds services for getting projections through Grpc and Rest (WebAPI)

Added

• Grpc service for getting projections
• Rest (WebAPI for getting projections

Summary

We saw inconsistent issues while committing events in applications with event handlers that caused the runtime to deadlock when committing an event, never returning.

Inspired by this blog post https://devblogs.microsoft.com/premier-developer/the-danger-of-taskcompletionsourcet-class/ we have a theory that it might be because when a TaskCompletionSource is being waited for and SetResult is called on it then all the task's async continuations will be invoked synchronously which could lead to a deadlock scenario. If that's the case then this issue can be resolved by giving the TaskCompletionSource the TaskCreationOptions.RunContinuationsAsynchronously flag when created to force the continuations to be run asynchronously.

We have yet to be able to write tests that provoke this scenario. Until then we can never know whether the issue has been resolved or not, or that that was the problem to begin with. I've added a single spec that failed when TaskCreationOptions.RunContinuationsAsynchronously was not given to the TaskCompletionSource and passes when it is. Thus IMO validating this fix

Changed

• Made EventWaiter more robust
• Added TaskCreationOptions.RunContinuationsAsynchronously to all manually created TaskCompletionSources

Added

• A spec that tries provoke the dead-lock by calling Notify and Wait in different threads and call Notify (running in separate thread from the thread calling Wait) between two Wait-calls. In this scenario the continuation of the first Wait call would be started synchronously, running on the thread that called Notify, after the Notify called TrySetResult on the TaskCompletionSource that the Wait-call awaits. And since the "Notify-thread" has the readWrite lock we get a dead-lock when the next Wait-call tries to get this lock.

FIxed

• A wrongly formatted log message when committing events.

Summary

A problem could occur when commiting multiple events because in regards to eventual consitency. This should likely solve that issue by notifying the event after the transaction has been committed.

Fixed

• Notify event waiter outside of the transaction

Linked to

• https://app.asana.com/0/1199901627887462/1199949796334295/f

Summary

First rough take on getting a RESTful API around the EventStore. Staying true to the gRPC protobuf contracts

Added

• Rest endpoints around the event store in a controller
• /api/event/commit - Commits events
• /api/event/commitForAggregate - Commits aggregate events
• /api/event/fetchForAggregate - Fetch events for aggregate

Changed

• Added a layer between the gRPC EventStore service and the Event Store which is a service that is a singleton per tenant. The new EventStore controller is also using it

Summary

Fixes a bug with our new ConceptAs type, that when trying to fetch nonexistent aggregate events, we would get a NullPointerException due to the implicit operator from ConceptAs not checking first for null.

Fixed

• Fix the implicit conversion on ConceptAs to check first if it's null
• Fix the ToString() on ConceptAs to check first if it's null
• Fix the AggregateRootVersion when converting CommittedAggregateEvents to their Protobuf representation when it was null

Summary

Remove unnecessary dependencies and rework some of the old fundamental parts of the code. Also update to . NET 5.

Added

• .editorconfig for enforcing our rules and styles

Changed

• Change to .NET 5
• Change old value type classes to be records to utilize the cool new C# 9 record type
• Changed most of the logging to utilise LoggerMessage both for performance gains and for keeping log messages together

Fixed

• Fixed a bug in a logging while filtering events
• Added calls to GC.SuppressFinalize() in Dispose() methods as per CA1816
• Many "constant" properties we're missing readonly keyword
• Fixed many using statements to the new simpler form
• Uses vars whenever possible now
• Start using new statements

Removed

• Remove Concepts and Value types - replace with records
• Remove Serialisation of Concepts
• Our custom logging wrapper around Microsofts own.
• Removed Validation as it was unused
• Remove custom Scheduler abstraction - the Runtime will always run in a multi-core, multi-threaded linux environment so we don't need to apply abstractions to performing scheduling tasks.
• Remove abstraction around time
• Remove InitialSystems bootstage
• Remove dependency to Dolittle.Common and use .editorconfig instead
• ILoggers from many classes where it wasn't being used