@maschwenk Could you follow the conventional commits? Thanks!

@maschwenk Could you follow the conventional commits? Thanks!

@matteovivona Totally, was just putting this here as a placeholder as I wasn't sure if this was an idea y'all would be on board with at all

@matteovivona would you accept this PR more or less as-is? (after adding testings and conventional commits, obviously)

I opted to not mount the route at all because I want to make sure it 404s instead of 500s or 200s. I believe Turborepo will retry on 500s and 200 ACKing feels kinda wrong.

Worth noting I'm also working with Turborepo to implement this at the Client level, but they have some concerns about how to make that functionality coherent with all the other flags they have

• Add support for read-only remote cache vercel/turborepo#6326

@fox1t @matteovivona The client-side flag actually landed in 1.10.17-canary.8 from

• Add support for read-only remote cache vercel/turborepo#6326

So I think this may not be necessary at all to implement server side. In fact in pretty much every way, it feels like a client side implementation is better.

@fox1t @matteovivona The client-side flag actually landed in 1.10.17-canary.8 from

• Add support for read-only remote cache vercel/turbo#6326

So I think this may not be necessary at all to implement server side. In fact in pretty much every way, it feels like a client side implementation is better.

OH! Awesome! We can skip to implement it here, even if I can see user cases where can be useful to have a server that can be reachable only in read mode.

@fox1t agreed. The server-side implementation use-case seems a little more fringey.