retrystate默认设置处理问题

[fibbery]

https://github.com/mosn/mosn/blob/f20464f60fe98cc69684bf3d510ce88214227841/pkg/proxy/retrystate.go#LL50C34-L50C35

	if retryPolicy.NumRetries() > rs.retiesRemaining {
		rs.retiesRemaining = retryPolicy.NumRetries()
	}

这里感觉可以直接改成如下

		rs.retiesRemaining = retryPolicy.NumRetries()

由用户自定义即可

[doujiang24]

这么改的话，会不会有就默认值的问题呢？
比如现在的逻辑是：用户没有配置，我们也默认有 3 次重试？

[fibbery]

这么改的话，会不会有就默认值的问题呢？ 比如现在的逻辑是：用户没有配置，我们也默认有 3 次重试？

我觉得就是正常场景，这个重试的策略就应该由用户自己去定义，而不应该给默认给重试三次。由用户选择性的做，而不应该强制做。
譬如目前的代码，我也无法控制只重试一次，也无法控制不重试

[doujiang24]

这里需要考虑向后兼容呢，可能有些老用户，升级了就不重试了，这个影响就大了呢

需求我觉得是合理的，不过得想个能向后兼容的实现

[spacewander]

可以设置成，一旦有用户配置的重试次数，那么就以用户的配置为准？

[fibbery]

我觉得可以，retryPolicy不为nil则该值设置的重试次数，反之使用默认设置的3次 罗泽轩 ***@***.***> 于 2023年6月12日周一 20:36写道：

…

可以设置成，一旦有用户配置的重试次数，那么就以用户的配置为准？ — Reply to this email directly, view it on GitHub <#2330 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBO37TT3IN6ESQN4JVHRADXK4EOBANCNFSM6AAAAAAZCY6XT4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[doujiang24]

有个问题是，这是来自 json 的配置，默认就是 0 呢
最好是，新增一个配置项，来改变这个行为，更加保险一些

[fibbery]

有个问题是，这是来自 json 的配置，默认就是 0 呢 最好是，新增一个配置项，来改变这个行为，更加保险一些
我觉得是

1. 默认行为，用户并不会主动配置这个RetryPolicyConfig吧，那实际上RetryPolicy就是nil的，那就用默认的3次配置
2. 如果用户配置了重试策略，我理解他知道配置的作用，那就按照他自定义的做处理吧

[fibbery]

感觉新增配置项，理解成本会增高

[doujiang24]

2. 如果用户配置了重试策略，我理解他知道配置的作用，那就按照他自定义的做处理吧

这里有问题呢，用户原来配置 RetryPolicyConfig，但是没有配置 num_retries，原来的逻辑是默认三次呢
如果直接改就是 0 了呢

如果没有历史负担，我是倾向于直接改的，但是有历史负担，还是要考虑下权衡，其实也是不太好权衡的

[fibbery]

2. 如果用户配置了重试策略，我理解他知道配置的作用，那就按照他自定义的做处理吧

这里有问题呢，用户原来配置 RetryPolicyConfig，但是没有配置 num_retries，原来的逻辑是默认三次呢 如果直接改就是 0 了呢

如果没有历史负担，我是倾向于直接改的，但是有历史负担，还是要考虑下权衡，其实也是不太好权衡的

我觉得这种可能性小，他既然到知道用配置了，肯定是知道重试机制的，不存在不配置次数吧，这个配置一共也没几个配置项

[doujiang24]

2. 如果用户配置了重试策略，我理解他知道配置的作用，那就按照他自定义的做处理吧

这里有问题呢，用户原来配置 RetryPolicyConfig，但是没有配置 num_retries，原来的逻辑是默认三次呢 如果直接改就是 0 了呢
如果没有历史负担，我是倾向于直接改的，但是有历史负担，还是要考虑下权衡，其实也是不太好权衡的

我觉得这种可能性小，他既然到知道用配置了，肯定是知道重试机制的，不存在不配置次数吧，这个配置一共也没几个配置项

这里不能假设肯定会配置呢，没有强制要求配置的，只能说可能性相对小

但是吧，重试这种东西，可大可小，而且有问题了，也不太好发现，真出了问题，其实是比较坑的

如果觉得加配置比较麻烦的话，可以新增一个全局变量当配置，通过变量来控制行为变化，然后暴露一个全局 API 函数来修改这个配置
可以默认用新的行为，通过调用这个全局 API（一个 Go 导出函数）来切到旧的行为
这样万一发现了问题，还有得机会改，不至于要回滚代码
保守的用户，也可以在升级到新版本的时候，默认调用这个全局 API