Built-in support for Active Failover

[JLedel]

If you're using an active failover setup and happens to query a follower, or there is a leader change, you'll get an exception telling that the node is not a leader anymore.

I guess the reasonable fix is to allow the HttpApiTransport class to be created with multiple endpoints, and then have the transport silently either try the other one suggested by the header, or just go through the list of provided servers until one that's leader is found.

Is there any interest to add support for this in this project as well? If so, we could try to coordinate it so that our implementation works for this connector as well.

[DiscoPYF]

Hi @JLedel , it makes sense to me to add support for this in this project.

I'm not familiar with the active failover sequence and implementation in ArangoDB, I will take a closer look. But at a glance I would propose to:

• Keep HttpApiTransport implementation as is.
• Create a separate implementation of IApiClientTransport that deals with active failover, e.g. FailoverHttpApiTransport.
  • Could possibly inherit from/extend HttpApiTransport, or use composition and FailoverHttpApiTransport just switch between multiple HttpApiTransport as needed. There are a few possibilities, I'm thinking outloud at this point.

What do you think?

[JLedel]

We looked at the go driver which just cycles between the connections until it finds a leader (for cluster as well): https://github.com/arangodb/go-driver/blob/ae64363de2bc9a13e5ef03115489e19fc9439793/cluster/cluster.go#L202

But yes, a FailOverHttpApiTransport would solve our case. We're working on it internally, so I'll make a PR once we've tested it a bit, and we can take it from there.

[DiscoPYF]

Sounds good 👍