stateful session header handling in strict mode when requested destination is not available

[ramaraochavali]

Currently when a stateful session in strict mode, when requested destination is not available responds with 503. But let's assume this flow

• Server is going through a rolling restart
• The Ingress Gateway Instance1 got the updated end point list
• The original client connects to Ingress Gateway Instance1 and session is established with backend, requested destination is set
• The original client makes request with the requested destination set. Now the request goes to Ingress Gateway Instance2. Let's assume Ingress Gateway Instance2 does not have those endpoints yet because of eventual consistency
  Now the request fails with 503. Clients can not retry 503 generally because of idempotency.

We need a mechanism for clients to know this is a retriable request. One option is we introduce a config that says "status_on_missing_destination" and clients can retry when they see this status.

Not sure if there other alternatives.

[ramaraochavali]

@wbpcode WDYT?

[agrawroh]

That sounds like a very useful feature! @wbpcode Would love to get your thoughts on this.

[yanavlasov]

503 is a retriable error code already, why would idempotency matter in this case? Are you suggesting adding config to return some other code in case there is no endpoint?

[ramaraochavali]

Correct. 503 is retriable error code but it is not safe to retry. I am suggesting to have another return code or some indication that it request failed because of absence of host

[yanavlasov]

I do not think there is a generic HTTP status that specifically indicates that request should be retried retry. One possibility is to set the Retry-After header, but it could be difficult to determine the time needed for endpoints to converge. You can add a config option to set a status code different from 503 but it would be up to the client to recognize that it has a special significance.

[ramaraochavali]

You can add a config option to set a status code different from 503 but it would be up to the client to recognize that it has a special significance.

That is the plan.

One possibility is to set the Retry-After header, but it could be difficult to determine the time needed for endpoints to converge

I thought about this idea. One disadvantage is it might get in to retry loop. Other way is to allow users to configure special retry policy when no-healthy-upstream happens and envoy doing internally doing retry.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[ramaraochavali]

Not stale. @envoyproxy/admins can you please mark it for "help wanted"?