Repository navigation
Allow code to detect when it is run inside a background job, as distinct from a remoting session #11293
Description
Summary of the new feature/enhancement
Behind the scenes, background jobs use the remoting infrastructure, which means that $PSSenderInfo is populated in both cases, and $Host.Name contains ServerRemoteHost.
Currently, it isn't always possible to detect when code is executing in a background job vs. when it is running in a true remoting session - but it should be possible to do so, reliably.
Proposed technical implementation details (optional)
Currently, $PSSenderInfo.ConnectionString contains the fixed string http://localhost in background jobs, whereas in WinRM-based remoting sessions the URL contains the actual host name, port number, and client PowerShell version.
However, in SSH-based remoting sessions, the same fixed string is currently used, which should be considered a bug - see #11292
Once #11292 gets fixed, testing $PSSenderInfo.ConnectionString -eq 'http://localhost' could serve as the test for detecting background jobs, but that is both obscure and technically incorrect - though it could serve as a solution if there's a backward compatibility concern over changing the value for background jobs.
Since there is no actual network connection involved in the case of background jobs (I presume), I suggest simply setting .ConnectionString to '' (empty string).
Activity
iSazonov commentedon Dec 9, 2019
An explicit value ("bgjob://") would show our intentions better.
mklement0 commentedon Dec 9, 2019
What matters at the end of the day is that we have some unambiguous value, so
bgjob://is an option too, albeit a somewhat artificial one in that no such protocol exists.What appeals to me about the empty string is that you don't have to remember an arbitrary identifier, but I don't feel strongly about this.
anmenaga commentedon Dec 9, 2019
What is an example of a scenario where the code needs to know if it is running in a background job or true remoting session?
mklement0 commentedon Dec 9, 2019
It came up in the context of #11270, where only true remoting contexts should fall back to legacy behavior in the absence of a
-PowerShellVersion 5.1argument, not also background jobs (where client and server are by definition the same PowerShell version) - though in the end it turned out that the distinction wasn't necessary.While I have no specific other use cases, it is conceivable that code would want to adjust its behavior depending on whether it's being executed in a true remoting session and/or a background job.
There's no reason not to enable such self-awareness, given that the pieces are already in place.
(And, as stated, the value
http://localhostin.ConnectionStringis misleading).microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.