Add tracing for file lines not dispatched to Transaction Processor #788

Summary

Investigate and add additional tracing for file-line processing paths where a line is not sent to the Transaction Processor, or where dispatch is attempted but the outcome is unclear from logs.

Findings

The dispatch call is in FileProcessor.BusinessLogic/Services/FileProcessorDomainService.cs at PerformTransaction (currently around line 426). It is reached only after token acquisition, merchant lookup, merchant-contract lookup, contract/operator matching, variable-value product lookup, and merchant-device resolution.

The following branches currently have limited or no diagnostic logging:

• Merchant lookup failure.
• Merchant-contract lookup failure or no contracts returned.
• No contract matching the file operator.
• No variable-value product on the selected contract.
• Missing or invalid merchant device data.
• Exceptions or cancellation before PerformTransaction.
• Event/MediatR dispatch failures between FileLineAddedEvent and ProcessTransactionForFileLine.
• PerformTransaction failures and non-0000 responses.
• Aggregate SaveChanges failure after a transaction was already sent.

Important behavior

At FileProcessorDomainService.cs around lines 356-360, a failed Transaction Processor call or a non-0000 response is converted into a Failed file-line state. The operation may therefore return successfully, and there is no dedicated log containing the file ID, line number, dispatch outcome, or original client error.

If the transaction is sent successfully but aggregate persistence fails afterward, the line can remain NotProcessed and may be retried, potentially causing a duplicate transaction. This needs clear tracing and investigation of the retry/idempotency behavior.

Suggested tracing

Add structured logs, at minimum including:

• File ID and line number.
• File profile/operator.
• Estate ID and merchant ID.
• Processing stage.
• Transaction Processor client operation and result/status.
• Response code/message where available.
• Whether the line was marked Failed and whether state persistence succeeded.
• Correlation/request identifier if one exists.

Suggested stages: line-processing-started, token-acquisition, merchant-lookup, contract-lookup, transaction-details-resolved, transaction-dispatch-started, transaction-dispatch-completed/failed, file-line-state-persisted/failed, and event-handler dispatch failure.

Acceptance criteria

• Every pre-dispatch exit is traceable to a specific stage and reason.
• Every PerformTransaction attempt logs file ID, line number, outcome, and response/error details without logging secrets or full sensitive transaction data.
• Persistence failures after dispatch are clearly distinguishable from failures before dispatch.
• Event-handler/MediatR failures identify the file and line where possible.
• Automated tests cover the new logging/diagnostic branches and preserve the existing line-state behavior unless a separate fix is agreed.