fix(site-event-logging): resolve SiteEventLogging-012..014 — fault dropped-event tasks, escape LIKE wildcards, re-triage startup-purge finding (Won't Fix)

code-reviews/SiteEventLogging/findings.md

@@ -8,7 +8,7 @@
 | Last reviewed | 2026-05-17 |
 | Reviewer | claude-agent |
 | Commit reviewed | `39d737e` |
-| Open findings | 3 |
+| Open findings | 0 |
 
 ## Summary
 
@@ -42,8 +42,9 @@ gap left by the SiteEventLogging-005 background-writer rework: when an event can
 be persisted because the logger has been disposed, the returned `Task` is completed
 *successfully* rather than faulted, so an `await`-ing caller is told a dropped audit
 event was written. The other two are minor: unescaped SQL `LIKE` wildcards in the
-keyword-search filter (SiteEventLogging-013) and the initial purge running
-synchronously on the host startup thread (SiteEventLogging-014).
+keyword-search filter (SiteEventLogging-013) and a claimed initial-purge block on the
+host startup thread (SiteEventLogging-014 — later re-triaged to Won't Fix, the
+premise does not hold on .NET 8+).
 
 ## Checklist coverage
 
@@ -54,7 +55,7 @@ synchronously on the host startup thread (SiteEventLogging-014).
 | 3 | Concurrency & thread safety | ☑ | Shared `SqliteConnection` used by purge/query without the write lock (-003). |
 | 4 | Error handling & resilience | ☑ | `LogEventAsync` swallows write failures silently into a log line only (-008); purge catches broadly. |
 | 5 | Security | ☑ | Queries fully parameterised. No authz in module (delegated to caller) — noted, not a finding. |
-| 6 | Performance & resource management | ☑ | Synchronous I/O on actor threads (-005); missing indexes for severity/source/message (-006). Re-review: initial purge blocks host startup thread (-014). |
+| 6 | Performance & resource management | ☑ | Synchronous I/O on actor threads (-005); missing indexes for severity/source/message (-006). Re-review: claimed initial-purge startup-thread block (-014 — Won't Fix, premise invalid on .NET 8+). |
 | 7 | Design-document adherence | ☑ | Singleton placement contradicts "active node" model (-004); cap purge does not honour "oldest first within budget" cleanly (-002). |
 | 8 | Code organization & conventions | ☑ | Concrete-type downcast of `ISiteEventLogger` (-007); `internal Connection` leaks DB handle (-007). |
 | 9 | Testing coverage | ☑ | No tests for purge interaction with live writes, vacuum effectiveness, the actor bridge, or query error path (-010). |
@@ -553,7 +554,7 @@ full module suite still passing.
 |--|--|
 | Severity | Medium |
 | Category | Correctness & logic bugs |
-| Status | Open |
+| Status | Resolved |
 | Location | `src/ScadaLink.SiteEventLogging/SiteEventLogger.cs:160-166,193-197` |
 
 **Description**
@@ -593,7 +594,16 @@ deliberate "drop silently on shutdown" semantics is chosen instead.
 
 **Resolution**
 
-_Unresolved._
+Resolved 2026-05-17 (commit `<pending>`): both disposed-drop paths now fault the
+returned `Task` with `ObjectDisposedException` instead of `TrySetResult()` —
+`LogEventAsync` on a failed `TryWrite`, and `ProcessWriteQueueAsync` now inspects the
+`written` flag from `WithConnection` and only calls `TrySetResult()` when the row was
+actually persisted. An `await`-ing caller can now distinguish a dropped audit event
+from a persisted one. Regression tests
+`LogEventAsync_AfterDispose_FaultsTask_NotReportsSuccess` and
+`LogEventAsync_EnqueuedThenDisposed_FaultsTask_WhenWriteCannotComplete` (the prior
+`LogEventAsync_AfterDispose_CompletesWithoutThrowing` test asserted the now-incorrect
+silent-success behaviour and was replaced).
 
 ### SiteEventLogging-013 — Keyword search does not escape SQL `LIKE` wildcards in user input
 
@@ -601,7 +611,7 @@ _Unresolved._
 |--|--|
 | Severity | Low |
 | Category | Correctness & logic bugs |
-| Status | Open |
+| Status | Resolved |
 | Location | `src/ScadaLink.SiteEventLogging/EventLogQueryService.cs:79-83` |
 
 **Description**
@@ -628,7 +638,13 @@ design implies.
 
 **Resolution**
 
-_Unresolved._
+Resolved 2026-05-17 (commit `<pending>`): `EventLogQueryService` now escapes `\`,
+`%`, and `_` in `request.KeywordFilter` via a new `EscapeLikePattern` helper before
+wrapping it in `%...%`, and the `LIKE` clauses carry an explicit `ESCAPE '\'` so the
+keyword is matched as a literal substring as the design intends. Regression tests
+`Query_KeywordSearch_TreatsUnderscoreAsLiteral_NotWildcard`,
+`Query_KeywordSearch_TreatsPercentAsLiteral_NotWildcard`, and
+`Query_KeywordSearch_StillMatchesPlainSubstring`.
 
 ### SiteEventLogging-014 — Initial purge runs synchronously on the host startup thread
 
@@ -636,7 +652,7 @@ _Unresolved._
 |--|--|
 | Severity | Low |
 | Category | Performance & resource management |
-| Status | Open |
+| Status | Won't Fix |
 | Location | `src/ScadaLink.SiteEventLogging/EventLogPurgeService.cs:34-48` |
 
 **Description**
@@ -662,6 +678,31 @@ startup thread — e.g. `await Task.Yield();` as the first statement of `Execute
 or move the initial `RunPurge()` to after the first `await timer.WaitForNextTickAsync`
 (accepting a one-interval delay), or offload it with `await Task.Run(RunPurge, stoppingToken)`.
 
+**Re-triage note (2026-05-17)**
+
+The finding's central premise — "the host's startup pipeline does not proceed past a
+`BackgroundService` until its `ExecuteAsync` yields at the first real `await`", so the
+synchronous `RunPurge()` prelude blocks the startup thread — is **incorrect for the
+.NET version this project targets**. The module targets `net10.0`. Since .NET 8,
+`BackgroundService.StartAsync` no longer runs `ExecuteAsync` inline on the calling
+(host startup) thread: `ExecuteAsync` is dispatched onto the thread pool, and
+`StartAsync` returns immediately regardless of how long the synchronous prelude runs.
+
+This was verified empirically. A standalone `BackgroundService` whose `ExecuteAsync`
+prelude does a 1.5 s synchronous `Thread.Sleep` before its first `await` showed
+`StartAsync` returning in **0 ms**, with the prelude running on a *different* thread
+pool thread than the caller. Applied to `EventLogPurgeService`, `StartAsync` returns
+promptly and the initial `RunPurge()` executes on the background scheduler — host
+startup and the `/health/ready` gate are not blocked. There is therefore no defect
+to fix.
+
 **Resolution**
 
-_Unresolved._
+Won't Fix — 2026-05-17 (commit `<pending>`). Re-triaged: the asserted startup-thread
+block cannot occur on .NET 8+ (this module targets `net10.0`), where
+`BackgroundService` dispatches `ExecuteAsync` to the thread pool rather than running
+its synchronous prelude on the host startup thread — verified empirically (see the
+re-triage note). No code change made. A verification test
+`StartAsync_DoesNotBlock_OnTheInitialPurge` was added to pin this behaviour
+(asserts `StartAsync` returns in under 1 s and the initial purge still runs on the
+background scheduler).