FST_ERR_CTP_INVALID_MEDIA_TYPE on PUT about turborepo-remote-cache HOT 5 CLOSED

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

from turborepo-remote-cache.

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?

from turborepo-remote-cache.

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.

from turborepo-remote-cache.

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!

from turborepo-remote-cache.

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.

from turborepo-remote-cache.