Publish fails for my custom location, but the error is odd

[jen_at_haverstack]

I've written a custom location plugin for ftrack-connect and the 'real' paths to file components show up correctly in the ftrack UI. I can also use the 'Open Directory' action successfully, etc.

My issue stems from publishing a version in Photoshop. The publish appears to fail (see attached), but the file is created in the correct place and the ftrack UI shows the new version and its corresponding component. If it didn't actually fail (from a practical standpoint), why am I getting this error?

The other thing to note is that I'm on a Windows 10 system, so the listed components configuration location is correct, but for some reason ftrack-connect wants it to be at a macOS location instead.

The ftrack-connect logs don't show an error, so I'm not sure how to troubleshoot this.

 

 

[JPrydz]

Hi Jen,

Welcome to the forum.
Could you please verify if you are logged in to Connect on multiple machines using the same account?
Both Mac and Windows?

Regards,
Johan

[jen_at_haverstack]

That was it! Thank you for your prompt response!

That brings me to a second question that is less pressing: shouldn't the `publish_components` hook only respond to events that were generated on the originating machine?

[Guest]

Hi Jen,

I think the issue is that we don't really know what's running on the same computer. With the Python API's event hub, we can either broadcast a message to the server, which is relayed to other listeners, or we can send that message to only the plugins that that API session has loaded. Setting aside the fact that the Adobe plugin is using Javascript (and doesn't have the local or synchronous option), there's still no middle ground of "transmit this event to other processes, but only those on my local machine". It would be possible to filter on the source id attribute of the event, but you'd still have to register each id as local--so every new browser session or new instance of Photoshop would have to get added to some list maintained by Connect. 

There are a few workflows that would benefit from that third option, and I have a rough proof of concept idea in my head, but we'd have to balance a more-thorough implementation with other priorities.

[jen_at_haverstack]

Ok, I see the dilemma. I was thinking the event should be filtered by the source ID, but hadn't considered other sources such as browsers complicating things. Thanks for clarifying!