You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which canary version will you have in your reproduction?
2.1.3-canary.1
Describe the Bug
Starting in version 1.13.4 there is an issue where AWS S3 presigned URLs return a 501 (Not Implemented) exception for PUT requests when used as a remote cache.
Turbo makes preflight request to AWS Lambda (possibly through an API Gateway)
Presigned URL is generated and returned to Turbo in the Location header
A presigned URL allows whoever has the URL to read / write from a given key in the storage bucket without any further authorization. It is valid for a limited amount of time which in the case of the reproduction is 1 hour.
Turbo makes PUT / GET request towards the presigned URL
The error occurs in this last request to the presigned URL
This setup should work and given that it already worked before 1.13.4 I think it's fair to say that there was some kind of regression that caused this.
Remember to delete the AWS resources again after debugging the issue :)
I think a good place to start would be to compare the HTTP requests going out in 1.13.3 (where it works) to those in 1.13.4 (where it stopped working). Maybe there actually is a difference in the headers like Stackoverflow suggests. I was unfortunately not able to find my way around the Rust code and couldn't look at the headers either since I was also not able to intercept the requests - but someone who knows Rust should be able to do so pretty easily.
Additional context
I tested in different canary releases. This was not a problem in any of the 1.13.4 canary releases. It occured between 1.13.4-canary.5 and 1.13.4.
Tagging @arlyon because you worked on remote cache stuff between these two versions, maybe you have an idea what caused this? :)
The text was updated successfully, but these errors were encountered:
Thanks for identifying where this stopped working. I think you're on the right path, maybe this line resulted in Content-Length not getting set due to size data getting lost. I can take a quick look into this.
Verify canary release
Link to code that reproduces this issue
https://github.com/puchm/turborepo-presigned-url-repro
What package manager are you using / does the bug impact?
npm, pnpm, Yarn v1, Yarn v2/v3/v4 (node_modules linker only)
What operating system are you using?
Mac
Which canary version will you have in your reproduction?
2.1.3-canary.1
Describe the Bug
Starting in version 1.13.4 there is an issue where AWS S3 presigned URLs return a 501 (Not Implemented) exception for PUT requests when used as a remote cache.
This can apparently be caused by a missing Content-Length header, although I wasn't able to determine if something changed in that regard.
Expected Behavior
The way this should work is as follows:
Location
headerThis setup should work and given that it already worked before 1.13.4 I think it's fair to say that there was some kind of regression that caused this.
To Reproduce
The reproduction is a modification of this repository: https://github.com/EloB/turborepo-remote-cache-lambdagit
I put a guide at the top of the README: https://github.com/puchm/turborepo-presigned-url-repro
Remember to delete the AWS resources again after debugging the issue :)
I think a good place to start would be to compare the HTTP requests going out in 1.13.3 (where it works) to those in 1.13.4 (where it stopped working). Maybe there actually is a difference in the headers like Stackoverflow suggests. I was unfortunately not able to find my way around the Rust code and couldn't look at the headers either since I was also not able to intercept the requests - but someone who knows Rust should be able to do so pretty easily.
Additional context
I tested in different canary releases. This was not a problem in any of the 1.13.4 canary releases. It occured between 1.13.4-canary.5 and 1.13.4.
Tagging @arlyon because you worked on remote cache stuff between these two versions, maybe you have an idea what caused this? :)
The text was updated successfully, but these errors were encountered: