IllegalStateException when using @PathVariable without name property

[Timeout-Timo]

Hi,

it seems like Feign (SpringBoot 4.0.3, Spring-Cloud-Dependencies 2025.1.1) does not support following client:

@FeignClient(name = "foo", url = "${service.foo}")
public interface FooClient {

    @DeleteMapping(path = "/api/foo/{id}")
    void delete(@PathVariable Long id);
}

I get the following exception:

Caused by: java.lang.IllegalStateException: PathVariable annotation was empty on param 0.
	at feign.Util.checkState(Util.java:118) ~[feign-core-13.6.jar:na]
	at org.springframework.cloud.openfeign.annotation.PathVariableParameterProcessor.processArgument(PathVariableParameterProcessor.java:52) ~[spring-cloud-openfeign-core-5.0.1.jar:5.0.1]
	at org.springframework.cloud.openfeign.support.SpringMvcContract.processAnnotationsOnParameter(SpringMvcContract.java:341) ~[spring-cloud-openfeign-core-5.0.1.jar:5.0.1]
	at feign.Contract$BaseContract.parseAndValidateMetadata(Contract.java:130) ~[feign-core-13.6.jar:na]
	at org.springframework.cloud.openfeign.support.SpringMvcContract.parseAndValidateMetadata(SpringMvcContract.java:205) ~[spring-cloud-openfeign-core-5.0.1.jar:5.0.1]
	at feign.Contract$BaseContract.parseAndValidateMetadata(Contract.java:71) ~[feign-core-13.6.jar:na]
	at feign.ReflectiveFeign$ParseHandlersByName.apply(ReflectiveFeign.java:140) ~[feign-core-13.6.jar:na]
	at feign.ReflectiveFeign.newInstance(ReflectiveFeign.java:59) ~[feign-core-13.6.jar:na]

However, if I use the name property, it resolves correctly and there is no error.

Since SpringBoot's default behaviour is based on the property name if not set, maybe it is useful to apply this to Feign-Clients as well

[ryanjbaxter]

Did this work in prior Spring Cloud versions?

[Timeout-Timo]

Honestly, I don't know. All I know is, that Spring Boot itself supports that in version 4 and IntelliJ keep complaining about redundance. But the redundance is necessary.

So it's maybe more like a feature than a bug.

[Timeout-Timo]

No, it wasn't supported. I've used git blame at the file that throws the Exception

It is indeed work as intended but maybe it should be changed to Spring MVC's default behaviour

[ryanjbaxter]

Can you provide a sample that reproduces this issue?