Closed bosschaert closed 2 months ago
Attention: Patch coverage is 88.46154%
with 3 lines
in your changes missing coverage. Please review.
Project coverage is 83.64%. Comparing base (
4224204
) to head (78f378e
).
Files | Patch % | Lines |
---|---|---|
src/storage/version/put.js | 88.00% | 3 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
What makes this different than our normal storage/object/put API? If I understand this correctly, it's because we're allowing plain strings for body as part of the API.
I would probably move to keeping this more aligned with the existing storage/object/put api... in fact, I would say we should explore reusing that and allow passing in metadata strings rather than building an entire new file we have to maintain just for versions.
I will beat this drum a lot, but it's only a matter of time before DA Admin becomes a complicated mess. When we provide many options of different ways to put something, we create complexity we will have to maintain for eternity. We should start with a consistent way to save data (body.data) and then only expand as real-world use cases are found.
I know our existing storage/object/put has some stuff in there for strings, but I think we need to move away from that... at the very least, standardize on the File detection that's already in there as well as the body.data
pattern that was established. Then we could re-use storage/object/put...
const body = {
data: new File(),
metadata: { users: '...' },
};
If if we do have to keep the put files separate, I would prefer if our data structures to save objects was as consistent as possible.
What makes this different than our normal storage/object/put API? If I understand this correctly, it's because we're allowing plain strings for body as part of the API.
Hi @auniverseaway we're actually not sending plain strings as part of the body of the version APIs. When content is saved with a version, this is purely a serverside operation, where the body content is streamed from one bucket to another. (@karlpauls correct me if I'm wrong).
This PR is to ensure that the ContentLength
property is set on the PutObject
API because otherwise it gives the warning mentioned above.
Having said that, I spoke to Karl and could simplify the implementation so that it doesn't need to read the stream to get its length as that information is already available as output of the getObject
API.
With that, the code now always has the ContentLength
without having to drain the data, whether the object being sent is a Stream (bucket-to-bucket copy), File (coming from the client) or String (generally an empty string ''
in case there is no body).
@auniverseaway @karlpauls this PR doesn't much change functionality but only fixes this error which is happening regularly on the servcer:
[ERROR] Are you using a Stream of unknown length as the Body of a PutObject
request? Consider using Upload instead from @aws-sdk/lib-storage.
The content length can in all cases be obtained from already available information, so no pre-streaming of content is needed.
Description
This fixes the following error that shows up in the da-admin console:
Related Issue
Fixes #43
How Has This Been Tested?
Types of changes
Checklist: