Messages not showing up in AzureLogAnalytics

[robabbott42]

I am using the AzureLogAnalytics PSFLoggingProvider from a GitHub action. The messages are only showing up in my Log Analytics about 40% of the time.

$paramSetPSFLoggingProvider = @{
Name = 'AzureLogAnalytics'
InstanceName = $LogType
WorkspaceId = $env:LOG_ANALYTICS_WORKSPACE_ID
SharedKey = $env:LOG_ANALYTICS_WORKSPACE_KEY
LogType = $LogType
Enabled = $true
}

Set-PSFLoggingProvider @paramSetPSFLoggingProvider
Write-PSFMessage -Message $Message -Level $Level
Wait-PSFMessage

[FriedrichWeinmann]

Not good, obviously.
You may need to update your call by a single line:

$paramSetPSFLoggingProvider = @{
	Name         = 'AzureLogAnalytics'
	InstanceName = $LogType
	WorkspaceId  = $env:LOG_ANALYTICS_WORKSPACE_ID
	SharedKey    = $env:LOG_ANALYTICS_WORKSPACE_KEY
	LogType      = $LogType
	Enabled      = $true
	Wait         = $true
}
	
Set-PSFLoggingProvider @paramSetPSFLoggingProvider
Write-PSFMessage -Message $Message -Level $Level
Wait-PSFMessage

Without the -Wait the message might be too soon and miss on the logging.
With the -Wait parameter set, Set-PSFLoggingProvider is going to block until it is certain the logging is good to go (which can be up to 5 seconds wait).
One of the regrets I have, where I wished I could travel back in time and fix it. But now it'd be a breaking change (even if a small one), and those I only do when I really have no way around it (like the recent security update).

Just realized I din't update my bloody examples .
Apologies, that is absolutely on my, I've made sure to fix that in the docs as well.

[AndiBellstedt]

@robabbott42
I had the same situation on my side with the LogAnalytics-Provider and the usage of the -Wait parameter fixes the issue.

@FriedrichWeinmann
maybe it is time for a V2 of PSFramework, where those breaking changes can be integrated. Probably, there are some more of those?!

[FriedrichWeinmann]

Yepp, I'm collecting those ... let's call them "Pseudo-Breaking"-changes - things that are an improvement, might break some things, but probably won't affect many/most. And are easy to mitigate for those impacted (in this case: Respecting -Wait:$false would do the trick).
Not sure when exactly I'm going to drop them - the security update would have been a good opportunity to do so - but it's going to be one big collection in a package, rather than dribbling them over time, on micro-break after the other.