Initialize telemetry context in UpdateTelemetryProperties if not already initialized

[adamint]

Description

Kusto exception data shows that we are missing data on several pages' component renders due to a OnParamsSet being called before we have reached telemetry context initialization in OnInitializedAsync. We can get around this by moving telemetry initialization to the top of each OnInitializedAsync. This problem only affects async component initialization but I moved every call for consistency.

Fixes part of #9534

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue (consider using one of the following templates):
      • New (or update) doc-idea template
      • New breaking-change template
      • New diagnostic template
  • No

[Copilot]

Pull Request Overview

This PR ensures the telemetry context is initialized at the very start of each component’s lifecycle method to prevent missing telemetry when async parameter sets occur before initialization. The key changes are:

• Add TelemetryContextProvider.Initialize(TelemetryContext) at the top of each OnInitialized/OnInitializedAsync.
• Remove duplicate initialization calls at the end of those methods.
• Apply the pattern consistently across all dashboard page and control components.

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/Aspire.Dashboard/Components/Pages/Traces.razor.cs	Moved telemetry initialization to top of OnInitialized and removed duplicate.
src/Aspire.Dashboard/Components/Pages/TraceDetail.razor.cs	Same change in TraceDetail component.
src/Aspire.Dashboard/Components/Pages/StructuredLogs.razor.cs	Same change in StructuredLogs component.
src/Aspire.Dashboard/Components/Pages/Resources.razor.cs	Same change in Resources component’s OnInitializedAsync.
src/Aspire.Dashboard/Components/Pages/Metrics.razor.cs	Same change in Metrics component.
src/Aspire.Dashboard/Components/Pages/Login.razor.cs	Same change in Login component’s async init.
src/Aspire.Dashboard/Components/Pages/Error.razor.cs	Moved RequestId assignment after telemetry init for Error component.
src/Aspire.Dashboard/Components/Pages/ConsoleLogs.razor.cs	Same change in ConsoleLogs component.
src/Aspire.Dashboard/Components/Controls/ResourceDetails.razor.cs	Reordered telemetry init before grid label setup.

Comments suppressed due to low confidence (1)

src/Aspire.Dashboard/Components/Pages/Traces.razor.cs:152

• Consider adding a unit test to verify that TelemetryContextProvider.Initialize is called before any asynchronous lifecycle methods to ensure telemetry is always initialized in time.

TelemetryContextProvider.Initialize(TelemetryContext);

[Copilot]

[nitpick] Add a comment explaining why telemetry initialization is placed at the top of OnInitializedAsync, so future maintainers understand its importance before any awaits or parameter setup.

[JamesNK]

I'd like to understand the problem some more.

Is the problem that TelemetryContextProvider.UpdateTelemetryProperties is getting called on some pages before TelemetryContextProvider.Initialize is called? If that's the case, shouldn't we have seen errors from here when testing and using the app?

I like it would be a good idea to make PostProperties safer. If telemetry service isn't set then log a warning and skip calling PostOperation.

[adamint]

Yes, that’s exactly what’s happening (sometimes) in real dashboard use. To clarify, you would suggest also logging a warning instead of throwing ?

[JamesNK]

logging a warning instead of throwing ?

Yes

[JamesNK]

/backport to release/9.3

[github-actions]

Started backporting to release/9.3: https://github.com/dotnet/aspire/actions/runs/15359291327

[github-actions]

@JamesNK backporting to "release/9.3" failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch

Applying: Initialize telemetry before anything else is done
Applying: Log warning instead of throwing an exception if telemetry service is null in PostProperties
error: sha1 information is lacking or useless (src/Aspire.Dashboard/Components/Pages/ConsoleLogs.razor.cs).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0002 Log warning instead of throwing an exception if telemetry service is null in PostProperties
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!