-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
S3: Sending notification to EventBridge LIFECYCLE_TRANSITION_EVENT
#7448
base: master
Are you sure you want to change the base?
S3: Sending notification to EventBridge LIFECYCLE_TRANSITION_EVENT
#7448
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #7448 +/- ##
==========================================
- Coverage 95.88% 95.80% -0.08%
==========================================
Files 843 854 +11
Lines 82578 83957 +1379
==========================================
+ Hits 79178 80437 +1259
- Misses 3400 3520 +120
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds like a good usecase to introduce a getter/setter method for the storage_class
attribute.
If we send the event inside the setter method, we can be sure that this always happens - regardless of who/where/why the storage class was changed.
We'll just have to be careful to only send an event when there is a change, and not on initialization.
What do you think?
I totally agree with this :) |
we need the |
The |
from docs;
(I thought we can change object's storage class with
restore_object
request, but we can't based on the document.)