help request: is there plugin support auto retry the request when get error request or get specified httpstatus code?

[FinerKeysen]

Description

can apisix support retry request in following scenes:

• when get a specified httpstatus code, such as 5xx
• or when get an error request back, such as connection fail
• or when matched a specified respones header?

Environment

• APISIX version (run apisix version): 2.13.2
• Operating system (run uname -a): 20.04.1-Ubuntu
• OpenResty / Nginx version (run openresty -V or nginx -V): openresty/1.21.4.1

[Hazel6869]

@FinerKeysen hello, we can set the number of retries while passing the request to Upstream using the underlying Nginx mechanism. see: https://apisix.apache.org/docs/apisix/admin-api/#request-body-parameters-3

[FinerKeysen]

@FinerKeysen hello, we can set the number of retries while passing the request to Upstream using the underlying Nginx mechanism. see: https://apisix.apache.org/docs/apisix/admin-api/#request-body-parameters-3

yes, i find this parameter in upstream admin api, but it seems that it will effect all route who used this specified upstream. if i want to support retry in specified route, what should i do?

[soulbird]

Upstream retries at the route level are not yet supported.

[FinerKeysen]

Upstream retries at the route level are not yet supported.

will route level retry be supported in next version?

[soulbird]

Upstream retries at the route level are not yet supported.

will route level retry be supported in next version?

There are no plans for this yet, let's see if more people are interested in this feature.

[FinerKeysen]

Upstream retries at the route level are not yet supported.

will route level retry be supported in next version?

There are no plans for this yet, let's see if more people are interested in this feature.

ok, can i check request connection status or get the upstream respone in plugin level when a route use this plugin? i want to write a custom plugin to support it. is there any suggestion for me, thx?

[soulbird]

You can refer to the traffic-split plugin, set your own upstream, and dynamically set your retry parameters in the upstream.

[tzssangglass]

I would like to know in what scenario support for route level upstream retries is needed.

After all, retries are upstream oriented.

[FinerKeysen]

You can refer to the traffic-split plugin, set your own upstream, and dynamically set your retry parameters in the upstream.

ok, i'll read and make a try

[FinerKeysen]

I would like to know in what scenario support for route level upstream retries is needed.

After all, retries are upstream oriented.

for automatically review the error request call, i want to support it for user by setting conditions in following scence:

• Review conditions of the http protocol, when
  • 5xx，respones code
  • if connect-close、connect-reset、connect-timeout、connect-failure
  • refused code
  • retriable-status-codes，means specified status code
• Review conditions of the grpc protocol, when status code in response header：
  • cancelled
  • deadline-exceeded
  • internal
  • resource-exhausted
  • unavailable

[soulbird]

I would like to know in what scenario support for route level upstream retries is needed. After all, retries are upstream oriented.

for automatically review the error request call, i want to support it for user by setting conditions in following scence:

• Review conditions of the http protocol, when

  • 5xx，respones code
  • if connect-close、connect-reset、connect-timeout、connect-failure
  • refused code
  • retriable-status-codes，means specified status code

• Review conditions of the grpc protocol, when status code in response header：

  • cancelled
  • deadline-exceeded
  • internal
  • resource-exhausted
  • unavailable

It looks like you want to decide whether to retry or not based on the response from the previous request. Unfortunately, it cannot be achieved by developing custom plugins, because the balancer's hook is not exported to the plugin.

[tzssangglass]

for automatically review the error request call, i want to support it for user by setting conditions in following scence:

• Review conditions of the http protocol, when

  • 5xx，respones code
  • if connect-close、connect-reset、connect-timeout、connect-failure
  • refused code
  • retriable-status-codes，means specified status code

• Review conditions of the grpc protocol, when status code in response header：

  • cancelled
  • deadline-exceeded
  • internal
  • resource-exhausted
  • unavailable

IMO, this is not a reason to let retries by route be isolated. The purpose of retries is to find an available upstream, so the logic of retries should be generic, based on a common set of rules to decide whether to retry, e.g. timeout needs to be retried, but 404 response status actually does not need to be retried.

What you said looks more like logic that can be customized to determine if a retry is needed.

[FinerKeysen]

yes, maybe some conditions I list are not reasonable. Just for this kind customized need i want to support. For users, routing is a better understanding granularity in a gateway. The routing-level retry mechanism may also have a more applicable scene in the gateway。

[tzssangglass]

What you seem to need at the moment is a retry policy that is isolated for upstreams, i.e. each upstream has its own retry policy.

[FinerKeysen]

I would like to know in what scenario support for route level upstream retries is needed. After all, retries are upstream oriented.

for automatically review the error request call, i want to support it for user by setting conditions in following scence:

• Review conditions of the http protocol, when

  • 5xx，respones code
  • if connect-close、connect-reset、connect-timeout、connect-failure
  • refused code
  • retriable-status-codes，means specified status code

• Review conditions of the grpc protocol, when status code in response header：

  • cancelled
  • deadline-exceeded
  • internal
  • resource-exhausted
  • unavailable

It looks like you want to decide whether to retry or not based on the response from the previous request. Unfortunately, it cannot be achieved by developing custom plugins, because the balancer's hook is not exported to the plugin.

oh😅，sounds like I‘ve to do some work on kernel. I just know the way to wrtie a custom plugin. I need some time to learn the kernel code.

[FinerKeysen]

What you seem to need at the moment is a retry policy that is isolated for upstreams, i.e. each upstream has its own retry policy.

If multiple routes are bound to a certain upstream, the retry strategy associated with upstream will affect all routing. This may not be appropriate.

[tzssangglass]

If multiple routes are bound to a certain upstream, the retry strategy associated with upstream will affect all routing. This may not be appropriate.

ok, that was indeed a very special scene.

[tokers]

@FinerKeysen Could you give us an actual case about why we need to support the retry policy on the route level? I know that Envoy supports configuring retry policy both on the route and virtual host level.

[FinerKeysen]

@FinerKeysen Could you give us an actual case about why we need to support the retry policy on the route level? I know that Envoy supports configuring retry policy both on the route and virtual host level.

yes, envoy supported. upstream retry policy works smaller on granularity than route. the user could easily and flexiable to apply this strategy just like plugin and feel more directly, if supports. retry policy changes on upstream may effect multi route, but will not opposite.

[github-actions[bot]]

This issue has been marked as stale due to 350 days of inactivity. It will be closed in 2 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the [email protected] list. Thank you for your contributions.

[github-actions[bot]]

This issue has been closed due to lack of activity. If you think that is incorrect, or the issue requires additional review, you can revive the issue at any time.