Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add CLaSP Request Tracking #11015

Merged
merged 9 commits into from
Oct 16, 2024
Merged

Add CLaSP Request Tracking #11015

merged 9 commits into from
Oct 16, 2024

Conversation

ryzngard
Copy link
Contributor

@ryzngard ryzngard commented Oct 12, 2024

This adds the request tracking available for implementation in CLaSP for Razor.

TODO:

  • Add tests for new aggregate histograms
  • Double check telemetry disposal in VS and VS Code

/// of this class corresponds to a specific FunctionId operation and can support aggregated values for each
/// metric name logged.
/// </summary>
internal sealed class AggregatingTelemetryLog
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a comment in the code so that we can refer back to the original implementation later on?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can add a comment with a permalink. The implementation itself is fairly straight forward so I wasn't sure it was needed, but I wanted to give context on where I got it for the PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For sure, I just wondered if we wanted to capture the place to go look if we have questions or to see any updates.

/// <summary>
/// Manages creation and obtaining aggregated telemetry logs.
/// </summary>
internal sealed class AggregatingTelemetryLogManager : IDisposable
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dibarbet has a PR out removing the roslyn version of this class. You might want to coordinate with him before duplicating it.

dotnet/roslyn#75402

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question as before. Is this better placed in the code to make that connection with the Roslyn code a bit more permanent? If so, please use a permanent link in case the Roslyn file gets moved.

@ryzngard ryzngard marked this pull request as ready for review October 15, 2024 00:35
@ryzngard ryzngard requested a review from a team as a code owner October 15, 2024 00:35
@ryzngard ryzngard requested review from dibarbet and ToddGrun October 15, 2024 00:35
Comment on lines 53 to 56
public override void RecordWarning(string message)
{
_exception = new Exception(message);
_result = TelemetryResult.Failed;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whats the scenario for this? It's a little odd for "Warning" and "Failed" to be mixed. They don't mean the same thing to me. Should this be RecordFailure or RecordError? Even perhaps RecordException, but its just the convenience overload you can call if you just have a string.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. Capturing an exception for a warning and marking it as "failed" is surprising to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm going to remove the exception entirely. It's provided, but we don't record it in a normal histogram related way. It should get caught through fault reporting through

/// of this class corresponds to a specific FunctionId operation and can support aggregated values for each
/// metric name logged.
/// </summary>
internal sealed class AggregatingTelemetryLog
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a comment in the code so that we can refer back to the original implementation later on?

/// <summary>
/// Manages creation and obtaining aggregated telemetry logs.
/// </summary>
internal sealed class AggregatingTelemetryLogManager : IDisposable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question as before. Is this better placed in the code to make that connection with the Roslyn code a bit more permanent? If so, please use a permanent link in case the Roslyn file gets moved.

@@ -5,7 +5,7 @@

namespace Microsoft.AspNetCore.Razor.Telemetry;

internal interface ITelemetryReporter
internal interface ITelemetryReporter : IDisposable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this interface need to be IDisposable? Or, is it sufficient to mark TelemetryReporter as IDisposable? AFAICT, this isn't needed by the ITelemetryReporter contract itself and results in a do-nothing Dispose() on NoOpTelemetryReporter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is where my knowledge gets a little iffy. Disposal is handled by the DI implementation, and it's added as a singleton with AddSingleton<ITelemetryReporter>. Does DI know if the underlying class needs to be disposed? Do I need to add a finalizer pattern with disposal?

Copy link
Member

@DustinCampbell DustinCampbell Oct 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, all the DI containers we use -- MEF, Microsoft.Extensions.DependencyInjection, VSMEF -- will dispose the runtime object if it implements IDisposable. It is not necessary for the contract interface to be IDisposable. (Actually, it would be pretty weird if that was a requirement!)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just have blissful ignorance for MEF and VSMEF :) Will move IDisposable down


namespace Microsoft.AspNetCore.Razor.LanguageServer;

internal class CLaSPTelemetryService(ITelemetryReporter telemetryReporter) : AbstractTelemetryService
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess, consider marking this sealed too. 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:)

@@ -165,6 +165,7 @@ protected override ILspServices ConstructLspServices()
// TelemetryService.SetDefaultSession and provides the correct
// appinsights keys etc
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this comment in the right place? It's not clear to me what code it's referring to.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like it should just be removed

Copy link
Member

@DustinCampbell DustinCampbell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

@ryzngard ryzngard enabled auto-merge (squash) October 16, 2024 20:10
@ryzngard ryzngard merged commit d21c9c9 into dotnet:main Oct 16, 2024
12 checks passed
@ryzngard ryzngard deleted the clasp_telemetry branch October 16, 2024 20:40
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants