Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metadata option undefined on s3 bucket function #4898

Open
2 tasks done
andres091096 opened this issue Jan 31, 2024 · 4 comments
Open
2 tasks done

Metadata option undefined on s3 bucket function #4898

andres091096 opened this issue Jan 31, 2024 · 4 comments
Assignees
Labels

Comments

@andres091096
Copy link

Initial checklist

  • I understand this is a bug report and questions should be posted in the Community Forum
  • I searched issues and couldn’t find anything (or linked relevant results below)

Link to runnable example

No response

Steps to reproduce

I am using the metadata argument on the bucket function option to select the s3 bucket where I can upload the files. However, the argument is undefined. I follow this part of the documentation and I use this issue as a reference

This is part of my client config:

uppy.use(AwsS3,{
    shouldUseMultipart: (file) => file.size > 100 * 2 ** 20,
    companionUrl: 'http://localhost:3500',                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  
    allowedMetaFields: ['name', 'service'],
});

uppy.setMeta({service: 'profile'});

And this is my companion s3 config:

const uppyOptions = {
    s3: {
        key: '***',
        secret: '***',
        bucket: (req, metadata) => {
            console.log(metadata); // <-- undefined
            return 'uppy-demo';
        },
        region: 'us-east-1',
        getKey: (req, filename, metadata) => {
            console.log(metadata);  // <-- { name: 'pexels-2219024.jpg', service: 'profile' }
            return filename;
        },
    },
    providerOptions: {
        facebook: {
            key: process.env.COMPANION_FACEBOOK_KEY,
            secret: process.env.COMPANION_FACEBOOK_SECRET
        },
        instagram: {
            key: process.env.COMPANION_INSTAGRAM_KEY,
            secret: process.env.COMPANION_INSTAGRAM_SECRET
        }
    },
};

I investigated further and found that in some functions on the server component the metadata argument is not being passed, like here

Expected behavior

The metadata argument on the bucket will receive the user metadata like on the metadata argument on getKey option

Actual behavior

The argument is undefined

@mifi
Copy link
Contributor

mifi commented Jan 31, 2024

would you like to submit a PR? :)

@andres091096
Copy link
Author

I attempted to create a PR for this issue, but I encountered a hurdle related to multipart functions. Specifically, actions like abortMultipartUpload or signPartUpload require the bucket for execution. However, the requests for these actions lack metadata information, making it impossible to generate the bucket name.

A potential solution could involve implementing a mechanism similar to the one used for the key. This way, the createMultipartUpload method could return the bucket name, enabling its use in subsequent requests. I halted my PR attempt as I believe this decision might have significant implications.

@Murderlon
Copy link
Member

Maybe @aduh95 has some thoughts on that.

@aduh95
Copy link
Member

aduh95 commented Feb 1, 2024

Isn't the mecanism you're talking about what has been implemented in #4579?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants