Hey @nicholasdgoodman thanks so much for taking a look at this!
However, I did not experiment with very large attachments (>30MB) so will attempt that next.
This is the critical piece, I believe, because the scenario is when the event type is RejectedMessageError and the info is 'Document Is Too Large' . Recreating for sure requires sending in a very large binary attachment.
Are you checking the return code of ISession.Send(…) ?
Yes, it is coming back with an OK response. It is worth noting that we are using the Send(IMessage[], int int, out int) method (i.e. sending multiple messages) and that the out int messagesSent value is what we would expect.
Can you verify the queue received but rejected the message by going into the Broker Manager UI, Queues > { Queue Name } > Stats under the section “Incoming Messages Not Queued”?
It looks like these stats are zero, so the message never got to the queue. Could it be that Solace prevents them from even entering the Solace system because of the size limit being exceeded?
[D]oes your SendMessage() method actually return Task.CompletedTask or is that a workaround because of your issue?
No, it actually waits for all the tasks to complete and has some logic to handle errored flows. The code is something like the following.
public async Task SendMessages(…)
{
// see above
await WaitForAcknowledgements(messages);
}
public async Task WaitForAcknowledgements(IEnumerable<IMessage> messages)
{
var tasks = messages.Select(m ⇒ m.CorrelationKey).OfType<TaskCompletionSource>().Select(t ⇒ t.Task).ToList();
# Ensure we don't wait too long with a timeout
await Task.WhenAny(Task.WhenAll(tasks), Task.Delay(10000));
// Simplified logic for determining the success of the Tasks for demonstration purposes
if (tasks.Exists(t ⇒ !t.isCompleted))
{
throw new Exception("Something went wrong");
}
}