- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
Hi! Good question.
This is most likely caused by how enabling versioning on objects and deletion works. When versioning is enabled, a simple DELETE call does not permanently delete the object. Instead, S3 inserts a delete marker and the marker becomes the current version of the object with a new ID.
When trying to GET an object whose current version is a delete marker, Amazon S3 will behave as though the object has been deleted (even though it has not been erased) and returns a 404 error.
References:
Some more info re: the Schema aws.s3@ObjectDeleted. It appears that in the Schema definition, the versionId field is actually called 'version-id'. Maybe there is a disconnect here due to the difference in spelling between 'versionId' and 'version-id'.
Here is the relevant excerpt from the aws.s3@ObjectDeleted schema.
"Object": {
"type": "object",
"required": ["etag", "key", "sequencer"],
"properties": {
"etag": {
"type": "string"
},
"key": {
"type": "string"
},
"sequencer": {
"type": "string"
},
"version-id": {
"type": "string"
}
}
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 2 Jahren
Yes, but all objects and all delete markers in an S3 bucket with versioning enabled actually have version ids. And, if I don't use EventBridge and I just use the regular Event Notification stuff in S3, the S3Event objects that are sent to Lambda, SNS and SQS always include the VersionId in new objects and deleted objects.
I'm still holding out for another answer because the events and their payloads should have the same data especially when the Schema for the aws.s3@ObjectDeleted and aws.s3@ObjectCreated in EventBridge have a field for versionId.
TheSpunicorn