Bug: ROPs contained in digital assets need to be unlocked, so that sopoutput/Output File is writeable by the adaptor.

[andymanaws]

Describe the bug

Its common to wrap exporting into a digital asset at companies - Houdini offer it themselves via the filecache node which people again use a lot.

However, when using a locked digital asset, the sopoutput ( Output File) parameter cannot be written to - which I believe is a key requirement - of the SMF process ( or filepath mapping on SMF?)

If the ROP is inside a locked digital asset you get this error:

2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: 
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDOUT: Performing action: {"name": "start_render", "args": {"frame_range": {"end": 1, "start": 1, "step": 1}}}
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR: Traceback (most recent call last):
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:   File "/sessions/session-26680be9828444b9a7a0df2d59cd4a3aqym832da/.env/opt/deadline-cloud-for-houdini/deadline/houdini_adaptor/HoudiniClient/houdini_client.py", line 65, in <module>
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:     main()
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:   File "/sessions/session-26680be9828444b9a7a0df2d59cd4a3aqym832da/.env/opt/deadline-cloud-for-houdini/deadline/houdini_adaptor/HoudiniClient/houdini_client.py", line 61, in main
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:     client.poll()
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:   File "/sessions/session-26680be9828444b9a7a0df2d59cd4a3aqym832da/.env/opt/deadline-cloud-for-houdini/openjd/adaptor_runtime_client/base_client_interface.py", line 212, in poll
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:     self._perform_action(action)
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:   File "/sessions/session-26680be9828444b9a7a0df2d59cd4a3aqym832da/.env/opt/deadline-cloud-for-houdini/openjd/adaptor_runtime_client/base_client_interface.py", line 233, in _perform_action
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:     action_func(a.args)
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:   File "/sessions/session-26680be9828444b9a7a0df2d59cd4a3aqym832da/.env/opt/deadline-cloud-for-houdini/deadline/houdini_adaptor/HoudiniClient/houdini_handler.py", line 124, in start_render
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:     self.node.parm("trange").set(1)
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:   File "/sessions/session-26680be9828444b9a7a0df2d59cd4a3aqym832da/.env/opt/houdini/houdini/python3.10libs/houpythonportion/Parm.py", line 87, in set
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:     self._set(value)
2025/04/25 12:54:58+00:00 ADAPTOR_OUTPUT: STDERR:   File "/sessions/session-26680be9828444b9a7a0df2d59cd4a3aqym832da/.env/opt/houdini/houdini/python3.10libs/hou.py", line 69838, in _set
2025/04/25 12:54:59+00:00 ADAPTOR_OUTPUT: STDERR:     return _hou.Parm__set(self, *args)
2025/04/25 12:54:59+00:00 ADAPTOR_OUTPUT: STDERR: hou.PermissionError: Failed to modify node or parameter because of a permission error.  Possible causes include locked assets, takes, product permissions or user specified permissions
2025/04/25 12:54:59+00:00 openjd_fail: Error encountered while running adaptor: Houdini exited early and did not render successfully, please check render logs. Exit code 1
2025/04/25 12:54:59+00:00 ERROR: Entrypoint failed: STDERR:     return _hou.Parm__set(self, *args)
2025/04/25 12:54:59+00:00 STDERR: hou.PermissionError: Failed to modify node or parameter because of a permission error.  Possible causes include locked assets, takes, product permissions or user specified permissions
2025/04/25 12:54:59+00:00 openjd_fail: Error encountered while running adaptor: Houdini exited early and did not render successfully, please check render logs. Exit code 1
2025/04/25 12:54:59+00:00 Process pid 11989 exited with code: 1 (unsigned) / 0x1 (hex)
No newer logs at this moment.

If you unlock the digital asset ( e.g. right click on a filecache , and Allow Editing of Contents) then the task works.

Expected Behaviour

The relevant digital assets need to be unlocked - Deadline Cloud will need to determine if the sopoutput parameter is writeable at submission time.

If not:

• at submission time, it could throw an error, and refuse to submit ( and let the artist figure it out)
• at submission time, it could ask the user if they would liek to unlock the relevant digital asset, and then perform the action on their behalf.
• at submission time, it does nothing, but at scene loading time, it could unlock the digital assets required to write. As long as the HIP is not saved during the render process ( its not right?) then its a transient action.

Current Behaviour

You get an error ( see above)

Reproduction Steps

Use a filecache node.
In OUT, drop down a fetch, point it to the filecache's ROP GEometry Output, plug it into a deadline cloud ROP, and submit.

Environment

At minimum:

1. Operating system Windows Server 2022
2. Version of Houdini: 20.0.724
3. Version of this package
4. If this is from a version installed by the Deadline Cloud Submitter installer, then what version of the submitter installer?

Please share other details about your environment that you think might be relevant to reproducing the bug.

[lucaseck]

Hey Andy, I was able to replicate this locally as well by creating some test geometry and feeding it into a filecache node. In /out I setup a fetch node and pointed it directly to the geo output within the filecache and then hooked that up into a Deadline Cloud node.

On initial run this did fail as expected with: ADAPTOR_OUTPUT: STDERR: hou.PermissionError: Failed to modify node or parameter because of a permission error. Possible causes include locked assets, takes, product permissions or user specified permissions .

We do have an option in the Job Specific Settings tab called Automatically unlock ROPs that I believe should handle this, but it doesn't appear to be working in this situation. Looks like a bug that will need fixing. Thanks for reporting.

[andymanaws]

I admit I was not aware of the unlock feature tucked away - nice!

I was going to ask if the submitter could warn if things are locked - but I also see looking at the code, that it should warn when it encounters locked ROPS (once working)

[lucaseck]

Just did some local testing and the fetch node appears to be the issue here. We never follow the fetch node to get the actual node it's referring to before checking if anything is locked and should be unlocked. I added some hacky code to follow the fetch node which did result in a warning popping up that locked ROPs were found and asking what I would like to do with them. Doing a submission after that did work and things were unlocked properly.

My hacky workaround that only follows the fetch node one level deep(can chain them if you really want to) was here:

    def _fetch_inner(node: hou.Node):
        inner_node = node.node(node.parm("source").eval())
        return inner_node

    # check for locked rops, Karma for example
    locked_rops = []
    for n in all_inputs:
        if n.type().nameWithCategory() == "Driver/fetch":
            n = _fetch_inner(n)
        node_path = n.path()
        if _is_node_locked(node_path):
            locked_rops.append(node_path)

A proper solution should follow any fetch nodes as far down a chain as they go to detect if there's anything to unlock. I'm also curious if there are other cases we are missing here. I know for detecting output directories we have to follow many other kinds of nodes not just fetch nodes to find paths etc that we need for submission.

[andymanaws]

AH interesting.

Fetch nodes are used a lot in centralising an asset specific / SOP specific location of export, into a global /OUT plan of execution.

Is there a plan to update support for the submitter to use them? I dont think you solution is a hack!

[lucaseck]

For sure, this is a bug and we should evaluate fetch nodes as part of looking for locked ROPs. I believe we already do follow them correctly in most other places. This could also likely use some investigation into if there are other cases missing from this code path that we need to be handling. My "hack" probably needs some expanding on and error case handling before it could be used as a mergeable solution, but may be a good starting point for when this gets prioritized and picked up for the fix.