From bd95f83282215974c9e3c89f4c5dea4109356dd5 Mon Sep 17 00:00:00 2001
From: mrchatam <287639636+mrchatam@users.noreply.github.com>
Date: Fri, 11 Sep 2026 23:07:55 +0000
Subject: [PATCH] docs: fix 'allows to' grammar in ADR 0043

---
 docs/decisions/0043-filters-exception-handling.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/decisions/0043-filters-exception-handling.md b/docs/decisions/0043-filters-exception-handling.md
index f10ffc9dc787..1cce018225d2 100644
--- a/docs/decisions/0043-filters-exception-handling.md
+++ b/docs/decisions/0043-filters-exception-handling.md
@@ -186,7 +186,7 @@ Advantages:
 
 - Native way how to handle and rethrow exceptions.
 - Similar to `IAsyncActionFilter` and `IEndpointFilter` API in ASP.NET.
-- One filter method to implement instead of two (`Invoking/Invoked`) - this allows to keep invocation context information in one method instead of storing it on class level. For example, to measure function execution time, `Stopwatch` can be created and started before `await next(context)` call and used after the call, while in approach with `Invoking/Invoked` methods the data should be passed between filter actions in other way, for example setting it on class level, which is harder to maintain.
+- One filter method to implement instead of two (`Invoking/Invoked`) - this allows you to keep invocation context information in one method instead of storing it on class level. For example, to measure function execution time, `Stopwatch` can be created and started before `await next(context)` call and used after the call, while in approach with `Invoking/Invoked` methods the data should be passed between filter actions in other way, for example setting it on class level, which is harder to maintain.
 - No need in cancellation logic (e.g. `context.Cancel = true`). To cancel the operation, simply don't call `await next(context)`.
 
 Disadvantages: