Share_thumbnail() broken?

Hey everyone,

Running into issues with the share_thumbnail() Python API method.

Sharing existing thumbnail

Trying to share an existing thumbnail:

shot = {"type": "Shot", "id": 162342}
asset = {"type": "Asset", "id": 215512}
result = shotgun.share_thumbnail(
    entities=[asset], 
    source_entity=shot
)

There’s no error but nothing happens and the thumbnail is not shared. This returns None, but the docs say this should be returning an Attachment ID as an int.

Sharing uploaded thumbnail

It also doesn’t seem to work anymore with uploaded files.

asset = {"type": "Asset", "id": 215512}
asset2 = {"type": "Asset", "id": 350867}
img = "/Users/kp/Pictures/iso50/st_helena_2021.jpg"
result = shotgun.share_thumbnail(
    entities=[asset, asset2], 
    thumbnail_path=img
)

Returns this error:

ShotgunThumbnailNotReady: Unable to share thumbnail: 2
source_entity image is a transient thumbnail that cannot be shared. Try again later, when the final thumbnail is available

cheers,
kp

It is in the documentation - an image can be “transient”, i.e. in flight, where a placeholder may be shown during this time.
It is up to you to check this condition. For example, if doing this in a Shotgun event handler, you can check the “is_transient” property as described here.

Yes, I saw that in the documentation. However, this then defeats the purpose of having an option in this method that allows you to upload an image as it will always be transient at this point, so it’s impossible to share it.

Additionally, I’ve discovered the issue with Case 1 above. If the source_entity thumbnail field is configured to display a thumbnail with a query, the share_thumbnail() method does nothing and returns None. This is despite when querying the entity outright, it showing an S3 URL for the thumbnail.

This method’s implementation now feels very inconsistent as it has the following undocumented behavior:

  1. If the source_entity calculates its thumbnail using a query, share_thumbnail() returns None and does nothing.
  2. If both the source_entity and “target” entity calculate their thumbnails using a query, share_thumbnail() returns None and does nothing.
  3. If the “target” entities calculates its thumbnail using a query, share_thumbnail() returns the Attachment id of the shared thumbnail, but this does not display on the target entity.

I think if the “target” entity is calculating its thumbnail using a query, this makes sense as I assume the value is being saved but overridden by the fact the target thumbnail is calculated and not explicit. However, if it’s only the source_entity that calculates it’s thumbnail, I think this method should be sharing the calculated thumbnail value.

And if uploading a thumbnail isn’t going to ever work as in Case 2 above, then it should be removed.

At the very least, it would be nice to update the documentation for this method with all of the details of this behavior so others don’t have to spend as much time figuring it out on their own.

cheers,
kp

Oh, now I see what you mean. Yeah, case 2 sounds like a bug, I agree!

For case 1 - if the thumbnail is not in flight it should work fine. Otherwise just yield and check later…? not sure how you are using it. If it is in Shotgun event daemon, then you will receive an event on both transitions and can react on the last one when the thumbnail is ready.

There’s no thumbnail in-flight in the case where we have a source entity and target entities so I’m not sure how yielding and checking later would change anything.

The current use-case is in an AMI but I’m speaking generally as well as we’d have other uses for this if it worked.

Alright, well in our specific case, we listen for versions being created/updated with a thumbnail. The first event, the thumbnail is still transient, and we skip that. Next time around, it is completed, and we successfully share the thumbnail with other related entities.

But maybe I am not fully understanding your case. I also don’t understand the “source entity calculating its thumbnail,” don’t know how this works.

Again, case 2 is certainly a bug.