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

React storage/cancel upload from process file #5179

Conversation

raystorm
Copy link

Description of changes

Adds support for the ability to cancel an Upload from processFile()
by returning a rejected promise.

Issue #, if available

#5099

Description of how you validated changes

  • Added a Unit Test to ensure removeUpload() is called when a rejected promise is returned from processFile().
  • Added a New Example, that forces a Promise.reject() in examples.
    ran the example manually with additional Logging code
    (not committed, and now removed to watch/verify operation.)

Checklist

  • Have read the Pull Request Guidelines
  • PR description included
  • Relevant documentation is changed or added (and PR referenced)
  • yarn test passes and tests are updated/added
  • No side effects or sideEffects field updated

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@raystorm raystorm requested a review from a team as a code owner April 24, 2024 21:22
Copy link

changeset-bot bot commented Apr 24, 2024

🦋 Changeset detected

Latest commit: af1f328

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@aws-amplify/ui-react-storage Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@calebpollman
Copy link
Contributor

calebpollman commented Apr 24, 2024

@raystorm Thanks for opening this! Need to discuss with the team, will update here once we have next steps

@calebpollman
Copy link
Contributor

@raystorm Just wanted to update you here, we are aligned with adding the update to processFile and will be reviewing your PR. Thanks again for contributing!

@calebpollman
Copy link
Contributor

@raystorm We recently made some updates to the StorageManager to support new functionality exposed on the uploadData API (consumed from aws-amplify/storage) used by the component, which has caused some merge conflicts with between main and your PR. Can help out with resolvng the merge conflicts, but wanted to give you the option to handle resolvng them i you prefer

  * move ProcessFile Error/reject handling to `getInput()`
@raystorm
Copy link
Author

@raystorm We recently made some updates to the StorageManager to support new functionality exposed on the uploadData API (consumed from aws-amplify/storage) used by the component, which has caused some merge conflicts with between main and your PR. Can help out with resolvng the merge conflicts, but wanted to give you the option to handle resolvng them i you prefer

Merge Conflicts are resolved. You may want to run the test example from my branch locally, to make sure everything still works properly. The Error Handling code is the same, but moved to getInput() I lost my local setup for running the examples, when I cleaned up some accidentally pushed env changes on my side. So I was unable to re-run the examples locally. as a secondary validation of my changes this time.

@raystorm
Copy link
Author

raystorm commented Jun 1, 2024

Not to be impatient, but is there any expected timeline for review/merge/release?

@calebpollman
Copy link
Contributor

Hey @raystorm, valid question. Have started reviewing, will finish the review in the next couple days. Thanks for your patience!

Copy link
Contributor

@calebpollman calebpollman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@raystorm Great start! The exception handling logic updates require changes to prevent calls to uploadFile on processFile error. Did not get in to reviewing the unit tests as they will need to be updated after the required changes are made

CONTRIBUTING.md Outdated Show resolved Hide resolved
1. Run `yarn setup`
1. [`nvm install`](https://github.com/nvm-sh/nvm)
1. [`nvm use`](https://github.com/nvm-sh/nvm)
1. Run `yarn setup` - _NOTE:_ if Cypress Fails to download during this step, delete `yarn.lock` and try again.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As noted previously, regenerating the yarn.lock can lead to unintended side effects. Please remove this change

packages/react/CONTRIBUTING.md Outdated Show resolved Hide resolved
packages/react/CONTRIBUTING.md Outdated Show resolved Hide resolved
packages/react/CONTRIBUTING.md Outdated Show resolved Hide resolved
packages/react/CONTRIBUTING.md Outdated Show resolved Hide resolved
} = await resolveFile({ file, key, processFile }).catch(
(result: ProcessFileParams) => {
const { key, error } = result;
if (isFunction(onUploadError)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the caught exception here is from resolveFile and not an upload error, this usage of onUploadError is incorrect and needs to be removed

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been commented out as incorrect, with a note, for a handler that might need to be added. Let me know if I should remove the code and the comment.

@@ -39,6 +39,7 @@ export type DefaultFile = Pick<StorageFile, 'key'>;
export interface ProcessFileParams extends Record<string, any> {
file: File;
key: string;
error?: string;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be removed, processFile should throw the underlying exception and be captured by the caller

Comment on lines 196 to 220
it('should remove upload after processFile promise rejects', async () => {
const processFile: StorageManagerProps['processFile'] = ({ file }) =>
Promise.reject({ file, key: 'test.png', error: 'forced test error' });

const { waitForNextUpdate } = renderHook(() =>
useUploadFiles({
...props,
isResumable: true,
processFile,
files: [mockQueuedFile],
})
);

waitForNextUpdate();

await waitFor(() => {
expect(mockOnUploadError).toHaveBeenCalledWith('forced test error', {
key: 'test.png',
});
});

await waitFor(() => {
expect(mockRemoveUpload).toHaveBeenCalled();
});
});
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@calebpollman, With your comments on my example is this Unit Test incorrect?
Should I only be testing a thrown Exception? or is that a second test case?

raystorm and others added 5 commits June 19, 2024 12:17
  + add new test case for `processFile` to verify throw errors are handled properly
  - remove `onUploadError` after processFile errors/rejects.
  - remove `yarn.lock` notes per PR Comments.
  + Add Prequesities to `react/CONTIRUBUTING.MD`
Update packages/react/CONTRIBUTING.md per PR Change Request

Co-authored-by: Caleb Pollman <[email protected]>
Update packages/react/CONTRIBUTING.md per PR Change Request

Co-authored-by: Caleb Pollman <[email protected]>
Update packages/react/CONTRIBUTING.md per PR Change Request

Co-authored-by: Caleb Pollman <[email protected]>
  - commented out error as an optional property
  * rename resolved -> rejected for clarity in `resolveFile.catch()` in `getInput()`
  * switched example from `Promise.reject()` to `throw new Error()`
@raystorm
Copy link
Author

raystorm commented Jul 7, 2024

@calebpollman I've made a lot of the changes you requested as I understood them.
It appears we have different visions for how this is to behave. I was just running the example locally, and for me, when I run examples/next/pages/ui/components/storage/storage-manager/process-file-reject it silently fails. So how should the end-user be notified that the uploaded file was rejected?

@raystorm
Copy link
Author

raystorm commented Jul 7, 2024

@calebpollman Looking at the latest merge conflicts with the new onProcessFileSuccess() method, are you now handling this ask internally in a different way? Should I expect this PR to be closed and not merged in favor of your internal solution?

@raystorm
Copy link
Author

raystorm commented Aug 5, 2024

@calebpollman I've made a lot of the changes you requested as I understood them. It appears we have different visions for how this is to behave. I was just running the example locally, and for me, when I run examples/next/pages/ui/components/storage/storage-manager/process-file-reject it silently fails. So how should the end-user be notified that the uploaded file was rejected?

@reesscot Are you on the team for this as well?

Having not seen a response, I am unsure how to proceed?
Thinking about it, I think a new optional function is needed, for the end user. onProcessFileError() or similar. Will there be any problems if I add a new function to the API? Or are you solving this internally?

@calebpollman
Copy link
Contributor

calebpollman commented Aug 6, 2024

Hey @raystorm, there's some problem areas in the upload input resolution we need to sort out in order to correctly address this. Would still like to get this in, but thinking that it might be more straightforward if we integrate your changes in with the input resolution refactoring, does that work for you?

@raystorm
Copy link
Author

raystorm commented Aug 6, 2024

I just want this resolved.
This is a blocking issue in my application right now.
I didn't expect this to take this long.
I'm just confused on what's going on, and the nature if the most recent updates with the onSuccess method, and what that means for my change.

Is there something I need to do to help move things forward?

@calebpollman
Copy link
Contributor

@raystorm Apologies here - there has been some churn on our end and we will work with you to get this resolved.

Regarding onProcessFileSuccess, it was added to address an issue with the value provided to onUploadSuccess not being the value that was provided to the upload call if updated through processFile, it was not intended nor it should impact the behavior you are implementing here.

  + add note about deleteing yarn.lock, so Cypress will download/install correctly
  + add `nvm install` & `nvm use` to react file.
  + add new test case for `processFile` to verify throw errors are handled properly
  - remove `onUploadError` after processFile errors/rejects.
  - remove `yarn.lock` notes per PR Comments.
  + Add Prequesities to `react/CONTIRUBUTING.MD`
  - commented out error as an optional property
  * rename resolved -> rejected for clarity in `resolveFile.catch()` in `getInput()`
  * switched example from `Promise.reject()` to `throw new Error()`
  + Add new `OnProcessFileError` function & `ProcessFileErrorParams` object
  * move error processing to inside resolveFile directly where processFile used.
  * update example with the new function.
…-processFile' into react-storage/cancel-upload-from-processFile

# Conflicts:
#	examples/next/pages/ui/components/storage/storage-manager/process-file-reject/index.page.tsx
#	packages/react-storage/src/components/StorageManager/hooks/useUploadFiles/__tests__/useUploadFiles.spec.ts
#	packages/react-storage/src/components/StorageManager/hooks/useUploadFiles/useUploadFiles.ts
#	packages/react-storage/src/components/StorageManager/types.ts
#	packages/react-storage/src/components/StorageManager/utils/__tests__/getInput.spec.ts
#	packages/react-storage/src/components/StorageManager/utils/getInput.ts
#	turbo.json
@raystorm
Copy link
Author

@raystorm Apologies here - there has been some churn on our end and we will work with you to get this resolved.

Regarding onProcessFileSuccess, it was added to address an issue with the value provided to onUploadSuccess not being the value that was provided to the upload call if updated through processFile, it was not intended nor it should impact the behavior you are implementing here.

I've done my best to FINALLY, get the merge conflicts resolved AGAIN.
I've also added a new function onProcessFileError and a new type, onProcessFileErrorParams. I've moved the error handling into resolveFile where it should have been in the first place so it directly responds to process file throwing an exception or rejecting.
Hopefully the new code meets with approval and we can finally get this PR done.

Copy link
Contributor

@reesscot reesscot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot of files being changed in this PR that aren't related to your change, so we're not going to be able to merge this as is. Can you please squash your changes and rebase them against the latest version of main? Looks like something went wrong with resolving merge conflicts.

"@aws-amplify/ui-react-storage": patch
---

fix(storage-manager): update file processedKey on process file complete
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this file is needed

@@ -14,30 +14,25 @@ function MyComponent() {
const [createLivenessApiData, setCreateLivenessApiData] = React.useState(null);

/*
* 1. Check whether the difference between server time and device time is
* greater than or equal to 5 minutes, and if so, return the offset in milliseconds.
* This logic should be adjusted based on the server response and use case
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these changes related to your PR? Same comment on all the other liveness files.

@@ -26,7 +26,6 @@ describe('useDataState', () => {
expect(action).not.toHaveBeenCalled();

expect(initState.data).toBe(initData);
expect(initState.hasError).toBe(false);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file shouldn't be getting changed

@raystorm
Copy link
Author

There's a lot of files being changed in this PR that aren't related to your change, so we're not going to be able to merge this as is. Can you please squash your changes and rebase them against the latest version of main? Looks like something went wrong with resolving merge conflicts.

@reesscot These changes are a result of a merge issue when pulling in the latest version from main to fix some merge issues, blocking the PR from being mergable. I'm not good enough with Git to quickly squash and rebase. So instead I've created a new branch and PR #5717
I am closing this PR for that one.

@raystorm raystorm closed this Aug 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants