Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken response streams #907

Open
13 tasks
drewvolz opened this issue Dec 7, 2024 · 0 comments
Open
13 tasks

Broken response streams #907

drewvolz opened this issue Dec 7, 2024 · 0 comments

Comments

@drewvolz
Copy link
Member

drewvolz commented Dec 7, 2024

Reopening from #901

Background

Checking on the changes pushed to the routes, we’re still dealing with streams being consumed more than once issue. Is it at an intercepted or middleware layer like we thought about before? docker-compose logs and the client app confirm we're still hitting these issues.

Issue

Response objects in ccc are being consumed more than once without being cloned first. If we are using the response body multiple times, which is a stream, it can't be read again, so we have issue.

$ docker-compose logs

TypeError: Response.clone: Body has already been consumed.
    at webidl.errors.exception (node:internal/deps/undici/undici:3384:14)
    at _Response.clone (node:internal/deps/undici/undici:8883:31)
    at result.<computed> [as json] (file:///app/node_modules/ky/distribution/core/Ky.js:55:48)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async getOlafAtoZ (file:///app/dist/source/ccci-stolaf-college/v1/a-z.js:23:41)
    at async atoz (file:///app/dist/source/ccci-stolaf-college/v1/a-z.js:49:24)
    at async bodyParser (/app/node_modules/koa-bodyparser/index.js:78:5)
    at async etag (/app/node_modules/koa-etag/index.js:27:5)
    at async /app/node_modules/koa-conditional-get/index.js:15:5
    at async compressMiddleware (/app/node_modules/koa-compress/lib/index.js:56:5)

The assumption being that this could be triggered by another request, logging, middleware, or most likely our mem caching.

The issue being the memoized response will return the same Response object, leading to an error if we are trying to access something on it.

This is what I am thinking is happening

  1. GET(url) makes the http request and returns a Response object
  2. .json() consumes the body of the Response
  3. Memoized GET(url) --> subsequent calls to GET(url).json() reuse the same Response object from first http call

I can point my physical phone at a local version of ccc but I haven't replicated the issue when running local ccc so far.

Endpoints (* means we've seen it error, ✔ means we've fixed it)

Preview Give feedback
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant