ID 495323 - When calling the metadata() method for a second time on a Read node in a terminal mode, the Read node is evaluated with "default" view, resulting in an error

Problem summary
When calling the metadata() method for a second time on a Read node in a terminal mode, the Read node is evaluated with "default" view, resulting in an error.
This issue does not appear to happen when executing the same code in a Nuke GUI session.

Customer reported version
Nuke 12.2v5

Customer reported platform
CentOS 6

Steps to reproduce

1) To reproduce this issue, you will need a script that has been set up for multiple views, and is reading in an EXR sequence with %V notation.

2) Launch Nuke via Command Prompt/Terminal using the -t flag.

3) Open the script in the terminal session, using the following command:

nuke.scriptOpen("path/to_some/script.nk")

4) Execute the following line of code. This should correctly print a dictionary of the Read node's metadata:

print(nuke.toNode("Read1").metadata())

5) Execute the same line of code a second time:

print(nuke.toNode("Read1").metadata())

RESULT: An error like the following should appear in the terminal session:

ERROR: Read1: C:/temp/test_default_0001.exr: Read error: No such file or directory

Expected behaviour
Calling the metadata() method on a Read node, twice in a row, should return the same result both times.

Actual behaviour
Calling the metadata() on a Read node in terminal mode works the first time. However, when it is called again, the Read node is evaluated with "default" view and this results in an error.

Workaround
Using the view argument in the metadata() method should always return the correct result. For example: 

print(nuke.toNode("Read1").metadata("exr/type", view="left"))

Reproduced by support
This bug has been reproduced in:
Nuke 13.0v5 - Windows 10 - macOS 10.13 (High Sierra) - Linux CentOS 7
Nuke 12.0v1 - Windows 10 - macOS 10.13 (High Sierra) - Linux CentOS 7

Unable to reproduce bug in:
Nuke 9.0v1 - Windows 10 - macOS 10.13 (High Sierra)

Earliest version tested
Nuke 9.0v1
- This issue doesn't appear in this version and has regressed