Hi @adornala, good find. That case isn’t handled well now, although it’s unfortunately a bit tricky to determine what the best behavior to implement is.
Since the sender’s sendMax and receiver’s receiveMax are denoted in different currencies, they cannot be compared directly.
If the sender determines the exchange rate, they could use that to try to figure out if their sendMax falls within the receiver’s limits and possibly fail faster knowing that it is impossible to send the full amount. However, both the exchange rate and the receiver’s receiveMax can change while the sender is sending and could make possible to send the full amount.
Alternatively, the sender could notice the specific case where they can’t send any more because they have already hit (or come very close to) the receiveMax and throw a specific error so you don’t need to wait for the timeout. However, this doesn’t help the main issue that you still haven’t been able to deliver the full amount that you wanted to send. Also, there are cases where you may want the sendMax to be higher than the receiveMax so that the receiver can pull money as needed, potentially as a streaming service is being rendered, so it’s a bit unclear whether not being able to send the full sendMax is an error in all cases.