I’m not sure of it all but
The final reason would seem to be in the SendHttpMessage failure posted earlier, and in both of your logs. What takes some guesses is why that happened, and my guess (confessing I’m not familiar with how the reports are built, including what lines go into for “Log data:” if it’s present), the kim-warning.txt was 82,142 bytes (cut-and-pasted) and I think .NET has a length limit of 0xFFF0, or 65,520. Some reports claim less.
Duplicati code I linked to earlier runs EscapeDataString, and here’s how it looks in MS Reference Source:
System.Uri.EscapeDataString calls
System.UriHelper.EscapeString compares length to
System.Uri.c_MaxUriBufferSize 0xFFF0
System.System.Net.Http.FormUrlEncodedContent(…) can’t handle very long parameters/values #1936 talks about this known (at least to the .NET developers) limitation, and how one might code a workaround.
In order to know that this is actually what happened, you could create a test case that sends a long report into your reporting server (for example a per-file warning), and search (maybe binary search) for fail point. That can then become a Duplicati Issue to await its turn. Could take awhile. Your checking on non-reports would be wanted anyway, and might suffice if a flood of warnings manages to break the report of the flood.
New log system with filters was a report of the same exception, so I might point back at the theory here…
Whether or not you feel like an extra chase, I’m glad the rest turned out well, including chasing loose ends.