java.lang.IllegalStateException: The response object has been recycled and is no longer associated with this facade

[jialiangyin168]

Integration

sentry

Java Version

17

Version

6.17.0

Steps to Reproduce

1. on Spring boot & webflux, make a gRPC call

2. oftentimes get an error: java.lang.IllegalStateException: The response object has been recycled and is no longer associated with this facade

3. When we remove sentry in project, there is no errors. Here is sample code:

   
   //deviceService is a gRPC stub
   final DeviceServiceGrpc.DeviceServiceStub deviceService = this.userDeviceRelationClient.getDeviceServiceStub();
   //make a gRPC call
   final Mono<GetCoreDumpUploadUrlResponse> responseMono = Mono.create(emptyMonoSink ->
               deviceService.getCoreDumpUploadUrl(request, MonoUtil.createStreamObserver(emptyMonoSink)));

//MonoUtil.createStreamObserver code public static StreamObserver createStreamObserver(final MonoSink monoSink){ return new StreamObserver() { @Override public void onNext(V v) { monoSink.success(v); }

        @Override
        public void onError(Throwable throwable) {
            monoSink.error(throwable);
        }

        @Override
        public void onCompleted() {
            // DO NOTHING
        }
    };
}

### Expected Result

no errors

### Actual Result

java.lang.IllegalStateException: The response object has been recycled and is no longer associated with this facade

[kahest]

Thanks for the detailed report 🙏 we'll investigate and get back to you

[jialiangyin168]

Thanks for your attention. Waiting for your reponse

[adinauer]

@jialiangyin168 what version of Spring (Boot) are you using?

I assume the GRPC call is happening on your Spring backend but is triggered by an HTTP call into your Spring backend. Does this HTTP call fail due to the error you mentioned or is it just logged but the HTTP request succeeds?

Does this not happen for requests where you do not perform a gRPC call?

Also is this a fire and forget operation or are you waiting for the response of the gRPC call?

[jialiangyin168]

@adinauer the version of Spring (Boot) is 3.0.6. Although there are some errors of java.lang.IllegalStateException, I haven't notice any other effect. The http calls are successful. The server side which is reactive is developed by spring & webflux, so we are not waiting for the response of the gRPC call. here is the pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.0.6</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-webflux</artifactId>
        </dependency>
     </dependencies>
</project>

[jialiangyin168]

@adinauer Here is the sample code of our API:

@RestController
@RequestMapping("/device")
public class DeviceController {
    @PostMapping("/get_upload_url")
    public Mono<ResponseResult> getUploadUrl(@Validated @RequestBody final UploadRequest request) {
        //make a gRPC call
    final Mono<GetUploadUrlResponse> responseMono = Mono.create(emptyMonoSink ->
                deviceService.getUploadUrl(request, MonoUtil.createStreamObserver(emptyMonoSink)));
        return responseMono.map(ResponseResult::success);
    }
}

[adinauer]

Thanks we'll take a closer look but can't say when exactly. Sounds like you're not blocked by this and users are not experiencing any problems due to this. If this isn't the case please let us know so we can bump priority.

Probably fine if we simply wrap the access to response in onComplete with try/catch to swallow the error and not set status (code) in that case. Ideally I'd like to setup a test sample and attach a debugger and poke around a bit as there might be more to it.

[jialiangyin168]

@adinauer Thanks, we are not blocked by this issue.