Markdown linting: spacing around ordered lists

docs/articles/actors/dependency-injection.md

@@ -58,6 +58,7 @@ The `ServiceProvider.Props` method will accept additional arguments that can be
 Akka.DependencyInjection does not manage the lifecycle of your dependencies automatically - in fact, Akka.NET recommends that you follow [Microsoft's own dependency injection guidelines](https://docs.microsoft.com/en-us/dotnet/core/extensions/dependency-injection-guidelines):
 
 > Use the factory pattern to create an instance outside of the parent scope. In this situation, the app would generally have a Create method that calls the final type's constructor directly. If the final type has other dependencies, the factory can:
+>
 > * Receive an `IServiceProvider` in its constructor.
 > * Use `ActivatorUtilities.CreateInstance` to instantiate the instance outside of the container, while using the container for its dependencies.
 

docs/articles/actors/finite-state-machine.md

@@ -72,6 +72,7 @@ public class Buncher : FSM<State, IData>
 > The `FSM` class defines a receive method which handles internal messages and passes everything else through to the `FSM` logic (according to the current state). When overriding the receive method, keep in mind that e.g. state timeout handling depends on actually passing the messages through the `FSM` logic.
 
 The `FSM` class takes two type parameters:
+
 - the supertype of all state names, usually an enum,
 - the type of the state data which are tracked by the `FSM` module itself.
 

docs/articles/actors/mailboxes.md

@@ -23,7 +23,7 @@ To make an actor use a specific mailbox, you can set it up one of the following
   Props.Create<ActorType>().WithMailbox("my-custom-mailbox");
   ```
 
-2. In the actor's deployment configuration
+1. In the actor's deployment configuration
 
   ```hocon
   akka.actor.deployment {

docs/articles/actors/routers.md

@@ -285,7 +285,7 @@ There are 3 ways to define what data to use for the consistent hash key.
   });
 ```
 
-2. The messages may implement `IConsistentHashable`. The key is part of the message and it's convenient to define it together with the message definition.
+1. The messages may implement `IConsistentHashable`. The key is part of the message and it's convenient to define it together with the message definition.
 
 ```cs
   public class SomeMessage : IConsistentHashable
@@ -295,7 +295,7 @@ There are 3 ways to define what data to use for the consistent hash key.
   }
 ```
 
-3. The messages can be wrapped in a `ConsistentHashableEnvelope` to define what data to use for the consistent hash key. The sender knows the key to use.
+1. The messages can be wrapped in a `ConsistentHashableEnvelope` to define what data to use for the consistent hash key. The sender knows the key to use.
 
 ```cs
   public class SomeMessage
@@ -357,8 +357,9 @@ var router = system.ActorOf(Props.Empty.WithRouter(new ConsistentHashingGroup(wo
 ```
 
 > [!NOTE]
+>
 > 1. `virtual-nodes-factor` is the number of virtual nodes per routee that is used in the consistent hash node ring - if not defined, the default value is 10 and you shouldn't need to change it unless you understand how the algorithm works and know what you are doing.
-> 2. It is possible to define this value in code using the `WithVirtualFactor(...)` method of the ConsistentHashingPool/Group object.
+> 1. It is possible to define this value in code using the `WithVirtualFactor(...)` method of the ConsistentHashingPool/Group object.
 
 ### TailChopping
 
@@ -422,6 +423,7 @@ var router = system.ActorOf(Props.Empty.WithRouter(new TailChoppingGroup(workers
 ```
 
 > [!NOTE]
+>
 > 1. `within` is the time to wait for a reply from any routee before timing out
 > 2. `tail-chopping-router.interval` is the interval between requests to the other routees
 
@@ -483,6 +485,7 @@ var router = system.ActorOf(Props.Empty.WithRouter(new ScatterGatherFirstComplet
 ```
 
 > [!NOTE]
+>
 > 1. `within` is the time to wait for a reply from any routee before timing out
 
 ### SmallestMailbox

docs/articles/clustering/cluster-metrics.md

@@ -19,6 +19,7 @@ Metrics collection is delegated to an implementation of `Akka.Cluster.Metrics.IM
 
 Different collector implementations may provide different subsets of metrics published to the cluster. 
 Metrics currently supported are defined in `Akka.Cluster.Metrics.StandardMetrics` class:
+
 * `MemoryUsed` - total memory allocated to the currently running process
 * `MemoryAvailable` - memory, available for the process
 * `MaxMemoryRecommended` - if set, memory limit recommended for current process
@@ -35,6 +36,7 @@ which collects all metrics defined above.
 You can also plug-in your own metrics collector implementation.
 
 By default, metrics extension will use collector provider fall back and will try to load them in this order:
+
 1. configured user-provided collector (see `Configuration` section for details)
 2. built-in `Akka.Cluster.Metrics.Collectors.DefaultCollector` collector
 

docs/articles/concepts/addressing.md

@@ -110,6 +110,7 @@ will send msg to all siblings including the current actor.
 
 > [!NOTE]
 > What the above sections described in some detail can be summarized and memorized easily as follows:
+>
 > * `ActorOf` only ever creates a new actor, and it creates it as a direct child of the context on which this method is invoked (which may be any actor or actor system).
 > * `ActorSelection` only ever looks up existing actors when messages are delivered, i.e. does not create actors, or verify existence of actors when the selection is created.
 

docs/articles/intro/akka-users.md

@@ -23,6 +23,7 @@ Any system that has the need for high-throughput and low latency is a good candi
 #### Concurrency/parallelism (any app)
 
 Share of an article by Joel Mueller, Software Architect, SNL Financial
+
 * [SNL Financial (a subsidiary of McGraw Hill): Akka.NET Goes to Wall Street](https://petabridge.com/blog/akkadotnet-goes-to-wall-street/)
 
 #### Simulation
@@ -44,6 +45,7 @@ Scale up, scale out, fault-tolerance / HA
 #### Business Intelligence/Data Mining/general purpose crunching
 
 Tweet from Philip Laureano with links.
+
 * [Real-time Clickstream Processing at Domain.au with Octopus Deploy and Akka.NET](https://twitter.com/philiplaureano/status/735976018993778688)
 
 #### Internet of Things

docs/articles/networking/serialization.md

@@ -323,6 +323,7 @@ including JSON, BinaryFormatter, etc. In Akka, this issue primarily affects deve
 to unsecured Akka.Remote endpoints, a [practice that we do not encourage](https://getakka.net/articles/remoting/security.html#akkaremote-with-virtual-private-networks).
 
 Generally, there are two approaches you can take to alleviate this problem:
+
 1. Implement a schema-based serialization that are contract bound, which is more expensive to setup at first but fundamentally faster and more secure.
 2. Implement a filtering or blacklist to block dangerous types.
 

docs/articles/persistence/architecture.md

@@ -17,6 +17,7 @@ Akka.Persistence features are available through new set of actor base classes:
 - `SnapshotStore` is used to persist snapshots of either persistent actor's or view's internal state. They can be used to reduce recovery times in case when a lot of events needs to be replayed for specific persistent actor. Storage backend of the snapshot store is pluggable. By default it uses local file system.
 
 Receive Actors
+
 - `ReceivePersistentActor` - receive actor version of `UntypedPersistentActor`.
 - `AtLeastOnceDeliveryReceiveActor` - receive actor version of `AtLeastOnceDeliveryActor`.
 

docs/articles/persistence/persistence-testing.md

@@ -187,6 +187,7 @@ public class PersistentActorSpec : PersistenceTestKit
 ```
 
 Each method accepts 2 arguments:
+
 1. Behavior selector for operation under test;
 2. Actual code which must be tested when selected behavior is applied. 
 

docs/articles/persistence/persistent-views.md

@@ -6,6 +6,7 @@ title: Persistence Views
 
 > [!WARNING]
 > `PersistentView` is deprecated. Use [PersistenceQuery](xref:persistence-query) when it will be ported. The corresponding query type is `EventsByPersistenceId`. There are several alternatives for connecting the `Source` to an actor corresponding to a previous `PersistentView` actor:
+>
 > - `Sink.ActorRef` is simple, but has the disadvantage that there is no back-pressure signal from the destination actor, i.e. if the actor is not consuming the messages fast enough the mailbox of the actor will grow
 > - `MapAsync` combined with [Ask: Send-And-Receive-Future](xref:receive-actor-api#ask-send-and-receive-future) is almost as simple with the advantage of back-pressure being propagated all the way
 > - `ActorSubscriber` in case you need more fine grained control

docs/articles/remoting/deployment.md

@@ -6,6 +6,7 @@ title: Remote Deployment
 # Remotely Deploying Actors
 
 Deploying an actor means two things simultaneously:
+
 1. Creating an actor instance with specific, explicitly configured properties and
 2. Getting an `IActorRef` to that actor.
 

docs/articles/remoting/transports.md

@@ -19,12 +19,14 @@ Transports in Akka.Remote are abstractions on top of actual network transports,
 > Most of the information below are things you, as an Akka.NET user, do not need to care about 99% of the time. Feel free to skip to the [Akka.Remote's Built-in Transports](#akkaremotes-built-in-transports) section.
 
 Transports **do not need to care** about:
+
 * **Serialization** - that's handled by Akka.NET itself;
 * **Connection-oriented behavior** - the association process inside Akka.Remote ensures this, even over connection-less transports like UDP;
 * **Reliable delivery** - for system messages this is handled by Akka.Remote and for user-defined messages this is taken care of at the application level through something like the [`AtLeastOnceDeliveryActor`](xref:at-least-once-delivery) class, part of Akka.Persistence;
 * **Handling network failures** - all a transport needs to do is forward that information back up to Akka.Remote.
 
 Transports **do need to care** about:
+
 * **IP addressing and ports** - all Akka.NET endpoints have to be resolved to a reachable IP address and port number;
 * **Message delivery** - getting bytes from point A to point B;
 * **Message framing** - distinguishing individual messages within a network stream;

docs/articles/streams/basics.md

@@ -289,6 +289,7 @@ which will be running on the thread pools they have been configured to run on -
 ### Operator Fusion
 
 By default Akka Streams will fuse the stream operators. This means that the processing steps of a flow or stream graph can be executed within the same Actor and has two consequences:
+
 - passing elements from one processing stage to the next is a lot faster between fused stages due to avoiding the asynchronous messaging overhead
 - fused stream processing stages does not run in parallel to each other, meaning that only up to one CPU core is used for each fused part
 

docs/articles/streams/error-handling.md

@@ -146,6 +146,7 @@ For many stages it may not even make sense to implement support for supervision
 For stages that do implement supervision, the strategies for how to handle exceptions from processing stream elements can be selected when materializing the stream through use of an attribute.
 
 There are three ways to handle exceptions from application code:
+
 - `Stop` - The stream is completed with failure.
 - `Resume` - The element is dropped and the stream continues.
 - `Restart` - The element is dropped and the stream continues after restarting the stage. Restarting a stage means that any accumulated state is cleared. This is typically performed by creating a new instance of the stage.

docs/articles/utilities/circuit-breaker.md

@@ -39,6 +39,7 @@ The Akka.NET library provides an implementation of a circuit breaker called `Akk
 ### Initialization
 
 Here's how a `CircuitBreaker` would be configured for:
+
   * 5 maximum failures
   * a call timeout of 10 seconds
   * a reset timeout of 1 minute

docs/community/online-resources.md

@@ -14,6 +14,7 @@ title: Resources
 ## Blog posts
 
 **Petabridge**
+
 - [Akka.NET: What is an Actor?](https://petabridge.com/blog/akkadotnet-what-is-an-actor/) (Aaron Stannard on January 25, 2015)
 - [How to Do Asynchronous I/O with Akka.NET Actors Using PipeTo](https://petabridge.com/blog/akkadotnet-async-actors-using-pipeto/) (Aaron Stannard on January 27, 2015)
 - [How actors recover from failure](https://petabridge.com/blog/how-actors-recover-from-failure-hierarchy-and-supervision/) (Andrew Skotzko on February 6, 2015)
@@ -41,6 +42,7 @@ title: Resources
 - [Introducing Petabridge.Cmd - a Command-line Management Tool for Akka.NET Applications](https://petabridge.com/blog/petabridgecmd-release/) (Aaron Stannard on June 7, 2017)
 
 **Others**
+
 - [Deploying actors with Akka.NET](https://rogeralsing.com/2014/03/09/deploying-actors-with-akka-net/) (Roger Johansson on March 9, 2014)
 - [FSharp and Akka.net - the functional way](http://bartoszsypytkowski.com/fsharp-and-akka-net-the-functional-way/) (Bartosz Sypytkowski on July 5th, 2014)
 - [Map reduce with FSharp and Akka.net](http://bartoszsypytkowski.com/map-reduce-with-fsharp-and-akka-net/) (Bartosz Sypytkowski on July 8th, 2014)

docs/community/whats-new/akkadotnet-v1.4-upgrade-advisories.md

@@ -44,6 +44,7 @@ This setting is set of `on` by default and it resolves the backwards compatibili
 
 > [!IMPORTANT]
 > If you have: 
+>
 > * Previously upgraded to Akka.NET v1.4.20+ and you have not run into any issues;
 > * You have not yet upgraded to Akka.NET v1.4.20+; and
 > * You _do not_ plan on running both .NET Framework and .NET Core in the same cluster