Files marked as incomplete #809

Activity

1. StuartFerguson

   added the

   Investigation

   issue type on Sep 23, 2026
2. StuartFerguson

   added

   fileprocessing

   on Sep 23, 2026
3. StuartFerguson commented on Sep 25, 2026

   

   StuartFerguson

   on Sep 25, 2026 – with ChatGPT Codex Connector

   MemberAuthor

   More actions

   Investigation of FileAggregate-6dca2ab10bce4994c7d508206b0bedfe found that all source FileLineAddedEvent events exist, but line 7 has no terminal processing event.

   Observed stream sequence:

   • Lines 1, 9: FileLineProcessingIgnoredEvent
   • Lines 2–5 and 8: FileLineProcessingSuccessfulEvent
   • Line 6: FileLineTransactionDispatchFailedEvent only
   • Line 7: no processing result event
   • No FileProcessingCompletedEvent

   Suggested code changes:

   1. Propagate failed handler results from DomainEventHandlers.HandleDomainEvent. It currently awaits Task.WhenAll(tasks) but ignores the returned Result values and always returns HTTP 200. Failed processing should return a non-success response so EventStore retries the event.

   Result[] results = await Task.WhenAll(tasks);
   
   if (results.Any(result => result.IsFailed))
   {
       return Results.StatusCode(StatusCodes.Status500InternalServerError);
   }
   
   return Results.Ok();

   2. Prevent concurrent writes to the same FileAggregate. The subscription currently uses IsOrdered: false and InflightMessages: 100, allowing several lines from one aggregate to load/save concurrently. The short-term mitigation is ordered/single-inflight processing; the better long-term solution is aggregate/stream-keyed serialization.

   3. Ensure aggregate save/version conflicts remain retryable. ApplyFileUpdates converts exceptions and save failures into failed Result values, but those failures must reach the HTTP layer as non-success responses.

   4. Add tests for failed-result HTTP propagation, aggregate concurrency/save conflicts, idempotent redelivery, and retrying dispatch failures.

   5. Add recovery/monitoring for aggregates with lines still marked NotProcessed, since already-acknowledged events will not be retried automatically.

   The exact line-7 exception cannot be identified because the logs are no longer available, but the stream confirms that the input event exists and its processing result was never persisted.
4. StuartFerguson

   changed the issue type from

   Investigation

   to

   Bug

   on Sep 25, 2026
5. StuartFerguson

   linked a pull request that will close this issuereturn failures when a handler has actually failed :| #812on Sep 25, 2026
6. StuartFerguson

   closed this as completedin #812on Sep 25, 2026