$ZF(-100) with stdout/stderr redirect fails in irissession.exe but succeeds in InterSystems Terminal on Windows

[juanmotasanchez1-pixel]

LABEL: question

What we're trying to accomplish

We are building a full end-to-end CI/CD pipeline for an InterSystems IRIS project hosted on GitLab. The goal is for every push to the dev branch to automatically:

1. Pull the latest code from the GitLab repository into the IRIS namespace on the dev server (Pull(1))
2. Import and compile the updated classes into the IRIS namespace (ImportAll(1))

The pipeline runs on a GitLab Runner and uses PowerShell Invoke-Command over WinRM to reach the IRIS server, where it calls irissession.exe to invoke git-source-control's API:

script:
  - Invoke-Command -ComputerName "STL-IRIS-Dev" -ScriptBlock {
      irissession.exe IRISDEV1 -U "GITLABTEST" "##class(SourceControl.Git.API).Pull(1)"
    }
  - Invoke-Command -ComputerName "STL-IRIS-Dev" -ScriptBlock {
      irissession.exe IRISDEV1 -U "GITLABTEST" "##class(SourceControl.Git.API).ImportAll(1)"
    }

Pull(1) works correctly when called from an InterSystems Terminal session on the same server, but fails consistently when called via irissession.exe — both interactively and as a one-liner from the pipeline. ImportAll(1) succeeds in all contexts. The pipeline currently reports "Job succeeded" because ImportAll doesn't fail, but no new code is actually being pulled — it re-imports whatever was already on disk from a previous successful manual pull.

---

Environment

• InterSystems IRIS: 2025.1, Windows Server
• Namespace: GITLABTEST
• Invocation: irissession.exe IRISDEV1 -U "GITLABTEST" "##class(SourceControl.Git.API).Pull(1)"
• git-source-control: installed via ZPM in %SYS

Error

<NOTOPEN>RunGitCommandWithInput+197^SourceControl.Git.Utils.11

What we've isolated

The failure occurs at the $ZF(-100) call in RunGitCommandWithInput when launching a child process with stdout/stderr redirection:

set outLog = ##class(%Library.File).TempFilename()
set errLog = ##class(%Library.File).TempFilename()
set returnCode = $zf(-100, "/STDOUT="_outLog_" /STDERR="_errLog, gitCommand, args...)
; outLog file does not exist after this line — $ZF(-100) silently failed to write it
set outStream = ##class(%Stream.FileCharacter).%OpenId(outLog,,.sc)   ; <NOTOPEN> thrown here

Behavior by context

Context	Result
InterSystems Terminal (interactive logon)	✅ Pull(1) succeeds
irissession.exe (interactive)	❌ <NOTOPEN> at $ZF(-100)
irissession.exe one-liner (CI/CD pipeline via WinRM)	❌ <NOTOPEN> at $ZF(-100)

Direct file writes (##class(%Library.File).CopyFile, %Stream.FileCharacter, etc.) to the same temp path work correctly from both contexts. The failure is specific to child process launch via $ZF(-100) with /STDOUT= and /STDERR= redirect arguments.

What we've ruled out

• Not a GitLab/CI configuration issue
• Not a Git credential or repository state issue
• Not basic file permissions — direct writes to the same temp directory succeed from irissession.exe
• Not the temp directory path — the directory exists and is writable in both contexts

Question

Is there a known difference in how IRIS handles $ZF(-100) child process launching between an InterSystems Terminal session and an irissession.exe session on Windows?

Our hypothesis is that there is a difference in how child processes inherit handles, environment variables, or Windows security token attributes between the two session types. The Terminal session establishes a full interactive logon context; irissession.exe connects to the already-running IRIS service process as a network/non-interactive logon and may not have the same child-process launch capabilities.

We are planning to open an InterSystems WRC support case and would like to collect session environment and process-owner details from both contexts. Any guidance on what diagnostics would be most useful, or whether this is a known limitation of irissession.exe on Windows, would be appreciated.