Open o15a3d4l11s2 opened 4 months ago
Note that in the interceptor you linked from the tests that when the call is retried it creates a new call into which the buffered messages are sent:
In your code you're sending parts on the initial RPC which will be dropped if the RPC has already completed.
What are you trying to achieve?
The server sometimes returns errors or throttles the requests, so I want to be able to retry requests.
What have you tried so far?
Update: I also looked into https://github.com/grpc/grpc-swift/blob/945f7f779bbac0a201374a6e70f9d28e534f7cf7/Tests/GRPCTests/InterceptorsTests.swift#L225-L327 but once it retried, it did not get any response out. Also modified it to accommodate for doing N retries with a X seconds delay in between, but got multiple error while using.
Original: I have implemented what I think should be a sufficient interceptor for retrying, but now I start thinking if this is even possible from inside the interceptor itself.
Here is the sample code. The basic idea is that on sending the parts I store them for a possible retrying and if I receive response that is not OK or get a transport error, I just re-send the parts. But the problem is that after I re-send the parts, nothing happens - I get no more interceptor events at all and there is nothing happening at all based on the logs.