[BUG] Share expiration tasks fails when share is already revoked and has expiration #1749
Comments
TejasRGitHub
pushed a commit
to TejasRGitHub/aws-dataall
that referenced
this issue
Jan 31, 2025
TejasRGitHub
pushed a commit
to TejasRGitHub/aws-dataall
that referenced
this issue
Feb 3, 2025
# Conflicts: # backend/dataall/modules/shares_base/db/share_object_repositories.py
dlpzx
pushed a commit
that referenced
this issue
Feb 4, 2025
### Feature or Bugfix - Bugfix ### Detail - Simplified the logic for share item state transition - Resolved bug by adding ### Relates - (#1749) ### Testing 1. Created a share with expiration and all the share items are in Revoke_Succeded state. After running share exp task, no error were thrown ✅ 2. Created a share with expiration and few shares are in Share_Succeeded and few are in Revoke_Succeded state. After running share expiration task, share succeeded items were revoked successfully. ✅ 3. Share with expiration and items in Revoke_succeeded and few in revoke_failed, submitted, then share exp task doesn't process those items and doesn't throw any error ✅ ### Security Please answer the questions below briefly where applicable, or write `N/A`. Based on [OWASP 10](https://owasp.org/Top10/en/). - Does this PR introduce or modify any input fields or queries - this includes fetching data from storage outside the application (e.g. a database, an S3 bucket)? - Is the input sanitized? - What precautions are you taking before deserializing the data you consume? - Is injection prevented by parametrizing queries? - Have you ensured no `eval` or similar functions are used? - Does this PR introduce any functionality or component that requires authorization? - How have you ensured it respects the existing AuthN/AuthZ mechanisms? - Are you logging failed auth attempts? - Are you using or adding any cryptographic features? - Do you use a standard proven implementations? - Are the used keys controlled by the customer? Where are they stored? - Are you introducing any new policies/roles/users? - Have you used the least-privilege principle? How? By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. --------- Co-authored-by: trajopadhye <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When running share expiration task, all active shares with expiration are pulled in along with the share item
The current logic of updating the share item status puts all the share items in revoke_approved state and then revokes the share. While fetching the share items it only pull in the 'Share_Succeeded' state and then makes the transition
There is a bug in which if a share has all the share items in revoke succeeded state and then if the share also has an expiration date, then it calls the revoke_share function which results in the following error
An error occurred (UnauthorizedOperation) when calling RevokeItems operation: This transition is not possible, Revoke_Succeeded cannot go to ['Revoke_Approved']. If there is a sharing or revoking in progress wait until it is complete and try again. For share extensions delete unused items and try againHow to Reproduce
Create a share with expiration ( by enabling expiration on dataset )
Let the share expired and then run the share expiration task
The expiration task should fail
Expected behavior
No response
Your project
No response
Screenshots
No response
OS
Mac
Python version
3.9
AWS data.all version
2.6
Additional context
No response
The text was updated successfully, but these errors were encountered: