'Write-PSFMessage' intermittently not found - pipeline stops halfway through (Azure DevOps with Microsoft-hosted build agents running 'ubuntu-latest')

[jsandquist]

Anyone else seeing this in Azure DevOps using Microsoft-hosted build agents running 'ubuntu-20.04' ?

On my side we see this quite often - more or less daily actually. The solution is to manually re-run the failed pipeline a couple of times and it might succeed on the second, third, or fourth try or even later. We have 50+ build agents in the default 'Azure Pipelines' agent pool to pick from.

[daltondhcp]

I have not observed this previously. Does it always happen during subscription discovery or randomly? We have a new version of PSFramework coming in as part of #650 which is supposed to resolve issues related to runspaces, so might be something related to that. https://github.com/PowershellFrameworkCollective/psframework/blob/development/PSFramework/changelog.md#17235-2022-06-04

[FriedrichWeinmann]

Alas, the change is unrelated. The runspaces update was related to an error cleaning up memory, while this error is virtually guaranteed to be a module import issue. Which obviously should not be happening, so this is a curious issue.
Did you configure the agent in any particular way, or is this the plain default settings version?
Will try to recreate the issue and figure out what is happening.
I've created an issue to track this issue on the PSFramework end of things:
PowershellFrameworkCollective/psframework#528
Will look into it this weekend and update

[jsandquist]

Ah, interesting. Quite sure we only see this during subscription discovery with both 1.7 and 1.8 - unsure about earlier versions. BTW, due to #557 we are still using "Core.ThrottleLimit": 1,, but I see that setting is only used in Get-AzOpsResourceDefinition.

FWIW - I just noticed that all failed pipeline runs seem to crash after this last log entry:

[12:04:22][Get-AzOpsRoleAssignment] Retrieving Role Assignments at scope /subscriptions/...
but with a different error a few times

[jsandquist]

Sorry for the delay in responding here. I apparently forgot to mention that we used log level 9 instead of default 3:

  "PSFramework": {
    "Message.Info.Maximum": 9
  }

After setting it back to 3 we have not seen any of these errors again.