🐞 Bug: InternalServerError: stream is not readable when deploying to AWS (works locally)

[abhijit-hl]

When deploying Strapi with strapi-plugin-cache in an AWS environment (Kubernetes pods), the plugin throws the following error:

InternalServerError: stream is not readable at readStream (/opt/node_modules/strapi-cache/node_modules/raw-body/index.js:185:17) at executor (/opt/node_modules/strapi-cache/node_modules/raw-body/index.js:120:5) at new Promise (<anonymous>) at Object.getRawBody [as default] (/opt/node_modules/strapi-cache/node_modules/raw-body/index.js:119:10) at middleware (/opt/node_modules/strapi-cache/dist/server/index.js:232:52)

This does not occur in local development but consistently fails in production deployment on AWS.

Environment:

Strapi version: v5.14

strapi-cache plugin version: 1.5.5

Deployment: AWS (Kubernetes pods)

Node: 18.19.2

OS: Amazon Linux (EKS)

Works fine locally on Mac

[abhijit-hl]

@TupiC Can you comment on this ? Why this error is coming after adding a strapi cache library. It is not able to read the API from it's middleware.
Do I have to add strapi-cache in my config/middleware.js file explicitly ?

[TupiC]

Sorry, currently a bit busy. Sounds like a compression issue. Can you show me your middleware.ts?

[abhijit-hl]

here is middleware.ts file:
module.exports = [
'strapi::logger',
'strapi::errors',
{
name: "strapi::security",
config: {
contentSecurityPolicy: {
directives: {
"script-src": ["'self'", "'unsafe-inline'", "cdn.jsdelivr.net"],
"img-src": [
"'self'",
"data:",
"blob:",
"cdn.jsdelivr.net",
"strapi.io",
${process.env.AWAWS_BUCKETS}.s3.${process.env.AWS_REGION}.amazonaws.com,
${process.env.AWS_CDN},
],
},
},
},
},
'strapi::cors',
'strapi::poweredBy',
'strapi::query',
'strapi::body',
'strapi::session',
'strapi::favicon',
'strapi::public',
];

[TupiC]

Are you using GraphQL and do you know if AWS compresses your body?
Can you test if the issue persists with version 1.5.7-rc.1?

[abhijit-hl]

@TupiC No I am using REST API only and This error is coming just after starting strap in server, you can check this below
This is error coming from server logs:

[2025-07-29 11:26:23.729] info: [STRAPI CACHE] Initializing
[2025-07-29 11:26:23.730] info: [STRAPI CACHE] Initializing cache service from provider config...
[2025-07-29 11:26:23.730] info: [STRAPI CACHE] Selected cache provider: redis
[2025-07-29 11:26:23.732] info: [STRAPI CACHE] Redis provider initialized
[2025-07-29 11:26:23.733] info: [STRAPI CACHE] Plugin initialized
[2025-07-29 11:26:23.760] info: The Users & Permissions plugin automatically generated a jwt secret and stored it in .env under the name JWT_SECRET.
[2025-07-29 11:20:24.407] info: Strapi started successfully
[2025-07-29 11:20:28.528] error: [STRAPI CACHE] Redis get error: timeout
InternalServerError: stream is not readable
at readStream (/opt/node_modules/strapi-cache/node_modules/raw-body/index.js:185:17)
at executor (/opt/node_modules/strapi-cache/node_modules/raw-body/index.js:120:5)
at new Promise ()
at Object.getRawBody [as default] (/opt/node_modules/strapi-cache/node_modules/raw-body/index.js:119:10)
at middleware (/opt/node_modules/strapi-cache/dist/server/index.js:232:52)
at dispatch (/opt/node_modules/koa-compose/index.js:42:32)
at middleware$1 (/opt/node_modules/strapi-cache/dist/server/index.js:205:9)
at async middleware (/opt/node_modules/@strapi/core/dist/services/metrics/middleware.js:34:9)
[2025-07-29 11:20:28.530] error: [STRAPI CACHE] Redis get error: timeout
InternalServerError: stream is not readable
at readStream (/opt/node_modules/strapi-cache/node_modules/raw-body/index.js:185:17)
at executor (/opt/node_modules/strapi-cache/node_modules/raw-body/index.js:120:5)
at new Promise ()
at Object.getRawBody [as default] (/opt/node_modules/strapi-cache/node_modules/raw-body/index.js:119:10)
at middleware (/opt/node_modules/strapi-cache/dist/server/index.js:232:52)
at dispatch (/opt/node_modules/koa-compose/index.js:42:32)
at middleware$1 (/opt/node_modules/strapi-cache/dist/server/index.js:205:9)
at async middleware (/opt/node_modules/@strapi/core/dist/services/metrics/middleware.js:34:9)

[TupiC]

[2025-07-29 11:20:28.528] error: [STRAPI CACHE] Redis get error: timeout

Can you test setting cacheGetTimeoutInMs: 10000 in the plugin's config.

[abhijit-hl]

Same error I am getting after increasing cacheGetTimeoutInMs.
Error:

2025-07-29 11:50:04.217] error: [STRAPI CACHE] Redis get error: timeout
InternalServerError: stream is not readable
at readStream (/opt/node_modules/strapi-cache/node_modules/raw-body/index.js:185:17)
at executor (/opt/node_modules/strapi-cache/node_modules/raw-body/index.js:120:5)
at new Promise ()
at Object.getRawBody [as default] (/opt/node_modules/strapi-cache/node_modules/raw-body/index.js:119:10)
at middleware (/opt/node_modules/strapi-cache/dist/server/index.js:232:52)
at dispatch (/opt/node_modules/koa-compose/index.js:42:32)
at middleware$1 (/opt/node_modules/strapi-cache/dist/server/index.js:205:9)
at async middleware (/opt/node_modules/@strapi/core/dist/services/metrics/middleware.js:34:9)

[TupiC]

And you tested with 1.5.7-rc.1?

[abhijit-hl]

No , how to access this version 1.5.7-rc.1 ?

[TupiC]

Navigate to your package.json and replace your current version e.g. 1.5.5 with 1.5.7-rc.1:
"strapi-cache": "1.5.7-rc.1"
Please provide information once you could successfully install this version test @abhijit-hl

[abhijit-hl]

@TupiC It also might be related to our AWS Redis which might not be responding. Please give me sometime to test this and give you the conclusion. I am currently occupied in some another items in priority

[abhijit-hl]

@TupiC I got the issue. Issue was in Our AWS Redis Instance only , It was not responding so when I switched to older redis instance then it is working fine.

What Actually Happened

The plugin (like strapi-plugin-cache) likely tries to:
Connect to Redis
Cache or retrieve the response
Continue middleware chain
But when Redis is unreachable, it fails mid-stream, possibly leaving the request stream open or corrupted, hence stream is not readable.

Recommended Improvements:

• Gracefully handle Redis connection failures
• Return fallback response instead of letting raw-body crash
• Use ctx.req.readable checks before reading
• Add logging for Redis timeouts or failures

[abhijit-hl]

Question: Using existing Redis connection safely with strapi-cache

I have a few more questions regarding Redis:

Can we safely use an existing Redis connection?

Our application already maintains a Redis instance that is shared across other services (e.g.,Own org website etc.).

We want to confirm:

Is it safe to use the same Redis instance for this plugin?

Will strapi-plugin-cache touch or delete keys that it didn’t create?

✅ What can be done to isolate the plugin’s keys?
We noticed the plugin uses keys like strapi-cache:*. To avoid collisions or accidental deletions:

Can we define a custom key prefix (e.g., myapp:cache:)?

Does the plugin offer a way to namespace or segregate keys so it only purges its own entries?

When the plugin clears the cache, does it use FLUSHALL, or is it safely scoped with key patterns (e.g., DEL strapi-cache:*)?

What we’re looking for

We’d ideally like to:

• Use a shared Redis instance
• Ensure the plugin only deletes its own keys
• Avoid any accidental cache invalidation for other services using Redis
• If this isn’t fully supported yet, happy to collaborate or open a PR to allow:
• Configurable key prefixes
• Safe key clearing logic

@TupiC Please respond before closing this...

[TupiC]

The plugin will not touch or delete any other keys. Make sure to set autoPiugeOnStart to false (if using 1.5.7 or above) and make a backup before testing anything😉