客户端发起调用时配置重试次数时不生效

[EndlessSeeker]

Environment

• Server: dubbo-go 3.2
• Client: dubbo-go 3.2
• Protocol: triple

Issue description

在尝试客户端调用服务端，服务端报错的case时，发现客户端会默认重试3次，但是我指定服务调用的重试次数为1时，仍然会进行3次调用，重试的配置没有生效

	resp, err = svc.Greet(context.Background(), &greet.GreetRequest{Name: "wrong name"}, client.WithCallRetries(1))
	if err != nil {
		logger.Errorf("call Greet failed, err: %s", err.Error())
	}

Logs

client log

2024-02-28 17:57:49	ERROR	logger/logging.go:52	call Greet failed, err: [Failed to invoke the method Greet in the service greet.GreetService. Tried 2 times of the providers [tri://:@127.0.0.1:20000/?interface=greet.GreetService&group=&version= tri://:@127.0.0.1:20000/?interface=greet.GreetService&group=&version= tri://:@127.0.0.1:20000/?interface=greet.GreetService&group=&version=] (3/1)from the registry tri://127.0.0.1:20000/greet.GreetService?app.version=&application=dubbo.io&async=false&bean.name=greet.GreetService&cluster=failover&config.tracing=&environment=&generic=&group=&interface=greet.GreetService&loadbalance=&metadata-type=local&module=sample&name=dubbo.io&organization=dubbo-go&owner=dubbo-go&peer=true&provided-by=&reference.filter=cshutdown&registry.role=0&release=dubbo-golang-3.2.0&remote.timestamp=&retries=&serialization=protobuf&side=consumer&sticky=false&timestamp=1709114268&version= on the consumer 30.221.146.234 using the dubbo version 3.2.0. Last error is unknown: name is not right: wrong name.: unknown: name is not right: wrong name]

server log

2024-02-28 17:57:49     ERROR   logger/logging.go:32    [name is not right: wrong name]
2024-02-28 17:57:49     ERROR   logger/logging.go:32    [name is not right: wrong name]
2024-02-28 17:57:49     ERROR   logger/logging.go:32    [name is not right: wrong name]

[Phixsura]

dubbo-go/cluster/cluster/failover/cluster_invoker.go

Lines 107 to 120 in 52c8103

	func getRetries(invokers []protocol.Invoker, methodName string) int {
	if len(invokers) <= 0 {
	return constant.DefaultRetriesInt
	}
	url := invokers[0].GetURL()
	retries := url.GetMethodParamIntValue(methodName, constant.RetriesKey,
	url.GetParamByIntValue(constant.RetriesKey, constant.DefaultRetriesInt))
	if retries < 0 {
	return constant.DefaultRetriesInt
	}
	return retries
	}

默认走的是failover，可以看看这段代码，他实际上拿的是client上默认的retries，所以为重试2次

dubbo-go/cluster/cluster/failback/cluster_invoker.go

Lines 215 to 217 in 52c8103

	if retries, ok := invocation.GetAttachment(constant.RetriesKey); ok {
	rInt, _ := strconv.Atoi(retries)
	task.maxRetries = int64(rInt)

有意思的是，从源码可以看出WithCallRetries在failback策略是起作用的,反而WithClientRetries在failback不起作用

那么如果WithCallRetries的初衷是希望让本次调用走指定的次数，那么这里存在着bug
且如果WithCallRetries是默认让端上所有未定义的请求走指定次数，那这或许也存在bug，如果我理解没问题的话

[chickenlj]

那么如果WithCallRetries的初衷是希望让本次调用走指定的次数，那么这里存在着bug
且如果WithCallRetries是默认让端上所有未定义的请求走指定次数，那这或许也存在bug，如果我理解没问题的话

我觉得你的理解是正确的，这么做是合理的

[binksBrew]

resp, err := svc.Greet(context.Background(), &greet.GreetRequest{Name: "correct name"}, client.WithCallRetries(1))
if err != nil {
logger.Errorf("call Greet failed, err: %s", err.Error())
}

[FoghostCn]

is this issue resolved already?

[FinalT]

resolved in #2717