The `ByteReadChannel` passed as `response.content`...

# ktor

[ribesg]

The ByteReadChannel passed as response.content inside a ResponseObserver is now cancelled after updating from Ktor Client 1.3.0 to 1.3.2, what are we supposed to do with that?

[ribesg]

I’m trying to reimplement an interceptor close to ResponseObserver in my logging feature but half the things it uses are internal 😞

[ribesg]

Ok so it looks like it only happens on one of the endpoints I use, this endpoint’s response body is just OK. Maybe there’s a race condition that usually allows to log the body before the request’s scope/context disappears because it already takes time to read/deserialize it? And in this case as it’s just OK and I ignore the response (I’m doing a get<Unit>) the request is ended before the logging ends? I just don’t really know how all of this works, but would that make sense @e5l?

[e5l]

It looks like problem: could you confirm that if you’re using get<String> log contains response body?

[ribesg]

I’ll test that and get back to you it should take me half an hour (yay native compile times 😶)

[e5l]

It looks like get<Unit> cancell the response body and logging also cancels(and it looks like the expected behaviour)

[ribesg]

Ok, I would just expect anything present to be logged, even if not read/used by the user

[e5l]

Maybe we can add response was cancelled by user message, could you file an issue?

[ribesg]

But you’re right, if I know the endpoint returns a String, I should get a String. It’s my service that should return Unit, not the actual request

[ribesg]

Well yeah just a more clear message would help, I’ll open an issue

[e5l]

Awesome, thanks

[ribesg]

https://github.com/ktorio/ktor/issues/1735

[ribesg]

I changed get<Unit> to get<String> and there are no more errors 👍