NoSuchTagSet when calling the GetBucketTagging operation

[iby]

I have a bucket without any tags which results in the error when trying to list them.

  File "/usr/local/lib/python2.7/site-packages/botocore/client.py", line 310, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "/usr/local/lib/python2.7/site-packages/botocore/client.py", line 395, in _make_api_call
    raise ClientError(parsed_response, operation_name)
ClientError: An error occurred (NoSuchTagSet) when calling the GetBucketTagging operation: The TagSet does not exist

I'd expect it to return just an empty tag set like most other methods do.

[kyleknap]

Yeah that's strange. This is an error response coming from the S3. Most services though do not throw an error though if the list is empty, they just return an empty list. We may have to add a customization here based on S3's behavior, but we still need to do more research on what the right approach will be.

[iby]

Yep, I've googled up this in ruby sdk, which raised my eyebrows. On one hand 404 is a deviant, but sort of makes sense (when out of context), but in boto it's definitely an outsider.

[kyleknap]

Yeah I tried out the other SDKs that use resources like the ruby sdk and they have the same issue as boto so we will need to figure what the story will be:

2.2.3 :001 > require 'aws-sdk'
 => true 
2.2.3 :003 > s3 = Aws::S3::Resource.new(region:'us-east-1')
 => #<Aws::S3::Resource> 
2.2.3 :005 > bucket = s3.bucket('mybucketfoo')
 => #<Aws::S3::Bucket name="mybucketfoo"> 
2.2.3 :006 > tagging = bucket.tagging()
 => #<Aws::S3::BucketTagging bucket_name="mybucketfoo"> 
2.2.3 :007 > tagging.tag_set
Aws::S3::Errors::NoSuchTagSet: The TagSet does not exist

I think returning an empty list should be the behavior.

[iby]

👍 to that.

[jfarabaugh]

+1 Just hit this issue myself. will try / catch for now

[rayluo]

After research, it seems there is not much can be done here to change the behavior.

1. The underlying S3 GetBucketTagging operation purposely defines the "NoSuchTagSet" scenario as a "Special Error". Right now, all AWS SDKs just follow this behavior.
2. Depending on the perception, an empty list in this scenario is arguably a more intuitive behavior (more on this later). But even if that is the case, the proper place to address that is S3 GetBucketTagging to return an empty list in first place, and every SDK will naturally follow. We'd rather NOT do some customization in SDK to revert a behavior already (intentionally?) chosen by upstream service. Otherwise, should some day in future this operation return all THREE possible return values as a non-empty list, an empty list, and an explicit NoSuchTagSet error, our SDK won't be able to differentiate between the last two.
3. Interestingly, at the time of this writing, it turns out empty list is NOT even a proper value that can be accepted by put_bucket_tagging(), so it will be weird that if you could get an invalid value back from a get_bucket_tagging(), which you can not roundtrip back to put_bucket_tagging().
4. If you really want to dive deep, the truth is, from the API's perspective, S3's TagSet has never been designed as a list, unlike other tags (such as tags in EC2). The web console may make you think otherwise, but let's take a closer look into the underlying API. Its delete operation (see also our Boto 3 doc or botocore doc) provides no semantics to delete one tag among the tag set. You can only delete the entire tag set. Similarly, the put_bucket_tagging operation will overwrite all current tags, rather than append some into them. Which means, the real thing being Get/Put/Delete is actually a singular, not a collection. It is just that this singular, named TagSet, contains something happens to be a list, but TagSet itself is not a list. So you either have a TagSet or you don't. There is no such thing as empty list here.

In short, just use try / except to catch that error.

[jamesls]

Can we clarify whether we are taking about clients or resources? The original traceback didn't suggest resources, but @kyleknap's comments are using resources.

I agree that we shouldn't change the low level client API, but I still think at a high level, we should try to improve what we have in the resource model, especially if it's something we can model with some changes to the resource spec.

I definitely understand the customer request to succinctly get a set of tags, modify them, and update the bucket with the new tags. I'm in favor of making that easier to do at the resource level.

[rayluo]

So to document the off-line conversation.

• This is not a bug. And we are not going to change the low level client API behavior.
• It is still possible to do something in the higher level, probably something similar to waiters. This is considered as a feature request.

[lakshmigk01]

+1

[github-actions]

Greetings! It looks like this issue hasn’t been active in longer than one year. We encourage you to check if this is still an issue in the latest release. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or upvote with a reaction on the initial post to prevent automatic closure. If the issue is already closed, please feel free to open a new one.