This joins the existing instance routing: the request header fly-force-instance-id, or specifying instance in a fly-replay. In both of these cases, it’s all-or-nothing. The proxy will try really hard to get the request there, and will ultimately error if it cannot.
If those semantics aren’t quite right for your use-case, you can now use the request header fly-prefer-instance-id, or specify prefer_instance in a fly-replay. This is similar to fly-prefer-region, which is a weak preference. If the proxy can’t find that instance, or finds it unhealthy, the preference is discarded and the request gets load balanced again.
If you’re using instance routing for sticky sessions, but would rather the request land somewhere else under load, this change is worth exploring.
To answer your question with a question: If you were choosing between a replay targeting a different process group, or a replay targeting a different external port, does one option work better for you than the other?
both would work just as well! we’re looking to consolidate two apps into one for tighter blue-green deployments (where we currently do two blue-green deployments in sequence). we want to keep the processes independently scalable, without doing anything fancy with the machines api or putting our own reverse proxy in front. we would expose the “primary” on 80 and 443 and replay on the “secondary” on some other port
It would be awesome if this feature was supported also via cookie: an app can set a session cookie with fly-prefer-instance-id={instanceId} to easily get sticky sessions without too much code
This way you don’t need to manually update any client code or add a router machine in front to add replay headers