FST_ERR_CTP_INVALID_MEDIA_TYPE on PUT

[bmuenzenmeyer]

👋 Hello! Very excited to see this repo - got it up and running with the help of your stellar docs, but am now running into a problem.

{
  "severity": "ERROR",
  "level": 50,
  "time": 1642192525782,
  "pid": 17,
  "hostname": "REDACTED",
  "reqId": "REDACTED",
  "name": "FastifyError",
  "code": "FST_ERR_CTP_INVALID_MEDIA_TYPE",
  "message": "Unsupported Media Type: application/octet-stream",
  "statusCode": 415,
  "stack": "FastifyError: Unsupported Media Type: application/octet-stream\n    at ContentTypeParser.run (/home/app/node/node_modules/fastify/lib/contentTypeParser.js:142:16)\n    at handleRequest (/home/app/node/node_modules/fastify/lib/handleRequest.js:37:39)\n    at runPreParsing (/home/app/node/node_modules/fastify/lib/route.js:427:5)\n    at Object.routeHandler [as handler] (/home/app/node/node_modules/fastify/lib/route.js:385:7)\n    at Router.lookup (/home/app/node/node_modules/find-my-way/index.js:378:14)\n    at Router.defaultRoute (/home/app/node/node_modules/fastify/fastify.js:583:23)\n    at Router._defaultRoute (/home/app/node/node_modules/find-my-way/index.js:610:14)\n    at Router.lookup (/home/app/node/node_modules/find-my-way/index.js:376:36)\n    at Server.emit (events.js:400:28)\n    at Server.emit (domain.js:475:12)",
  "type": "Error",
}

Troubleshooting So Far

I am using the local filesystem approach, deployed in docker.

Trying to piece together the docs between here and turborepo, I don't know if
ENV VARS TURBO_TOKEN needs to be ANY string (the same in CLI and deployed in docker), or a bearer token.

I've also tried supplying --token and --api flag during commands. This seemed to help get calls through to the cache in addition to the valid .turbo/config.json apiUrl key

I am going to keep digging, including trying to run this locally, but wanted to document my current roadblock in the hopes it could help others.

[bmuenzenmeyer]

I pulled it down, (opening #7 along the way).

Following the docs, I was able to get remote cache hits locally, using the following steps:

# initial run, cache misses
npx turbo run build --api="http://localhost:3001" --token="abc123"

# second run, local cache hits, no output in locally running remote cache
npx turbo run build --api="http://localhost:3001" --token="abc123"

# delete local cache in my project
rm -rf ./node_modules/.cache/turbo

# third run, no local cache hits, success reading from the locally running remoter cache!
npx turbo run build --api="http://localhost:3001" --token="abc123"

So something in my deployment process or environment seems to be the culprit...

the error seems unrelated to authentication, but this is still very new to me.

[bmuenzenmeyer]

final update for the day, I can also run docker run --env-file=.env -p 3001:3001 fox1t/turborepo-remote-cache per the README and repeat the above steps - so I think there is something with the way I am trying to dockerize the image in my deployed environment, or the environment itself has quirks I do not yet understand.

stay tuned!

[fox1t]

Hi @bmuenzenmeyer, thanks for opening this issue. First of all, let me clarify the first point: TURBO_TOKEN value must be the same as the token provided to your Turborepo monorepo. So yes, basically there are the same, and the token is used for authenticating the requests.
Returning to your issue, it is a bizarre one. Fastify returns that error, the framework this project is based on. It happens when the incoming request doesn't have a proper parser. From your log, we can see that it is application/octet-stream, therefore the request should be parsed correctly since the content-type is correct and there is a custom parser here.

Where are you trying to deploy it? We deployed it successfully on docker and Kubernetes.

One final note: you don't need to pass --api="http://localhost:3001" to your build script if .turbo/config.json contains the apiUrl key since there are the same.

[fox1t]

I am closing this. Feel free to open a new one if the issue persists.

[itayganor]

We are facing the same issue on our server.

We are using the most recent version of turbo as well as this project. The same error message appears in the docker logs.

Is there any solution to this?