ID 591264 - Calling node.dependent() can return inconsistent results if the TCL expression "[dependencies this]" is used in a Text node

Follow

Problem summary:
Calling node.dependent() can return inconsistent results if the TCL expression "[dependencies this]" is used in a Text node 
 
This does not seem to affect node.dependencies()
 
Customer reported version:
Nuke 14.1v5
 
Customer reported platform:
Rocky9
 
Steps to reproduce:
1) Launch Nuke and create a Text node in the Node Graph.
2) In the Text node's Properties, enter [dependencies this] into the message field.
3) Create a Grade node that is connected to the Text node.
4) Open the Script Editor window and execute the following code, observing the output:

n = nuke.nodes.NoOp() nn = nuke.nodes.NoOp() nn.setInput(0, n) print(f"Attempt 1 - {n.name()}'s dependent nodes are: {n.dependent()}") print(f"Attempt 2 - {n.name()}'s dependent nodes are: {n.dependent()}")
# OutputAttempt 1 - NoOp1's dependent nodes are: [<Grade1 at 0x00000227EA4348A0>] Attempt 2 - NoOp1's dependent nodes are: [<NoOp2 at 0x00000227EA435DA0>]
 
Expected behavior:
Having the TCL expression [dependencies this] inside a Text node should not influence the node.dependent() Python function's results.
 
Actual behavior:
When a Text node exists inside the current Nuke script that includes [dependencies this] as a TCL expression, the node.dependent() method can produce incorrect/inconsistent results. 

This occurs whether or not the Preference for Expression evaluation mode is set to "Lazy" or "Always". Additionally, having the Text node's Properties open or closed does not alter the outcome, nor does adding forceEvaluate=True to the node.dependent() calls.
 
Workaround:
No known workaround at this time.
 
Reproduced by Support in:
Nuke 15.1v4 - Windows 10, macOS 14 Sonoma
Nuke 14.0v1 - Windows 10
Nuke 13.0v1 - Windows 10
Nuke 12.0v1 - Windows 10
 
Earliest version tested:
Nuke 12.0v1 - This issue appears to be in all tested versions of the product 

    We're sorry to hear that

    Please tell us why