Skip to content

dotnet tracing docs outdated #14965

@sfanahata

Description

@sfanahata

https://docs.sentry.io/platforms/dotnet/tracing/instrumentation/custom-instrumentation/queues-module/

  1. This page mentions that queue instrumentation is automatic if we're using a supported framework, but doesn't list that those supported frameworks are.
  2. The C# code samples have case-sensitivity typo's in them - referenceing getTraceHeader and getBaggage methods, but in the C# SDK, those are GetTraceHeader and GetBaggage.
  3. The code sample for queue message producer instrumentation (first sample block on page) doesn't work. It's missing extra steps to set up a Trace Continuation that are present in the second snippet, and necessary for this to work as intended.
  4. The page doesn't clarify which parts are mandatory for makng the integration with sentry's queue insights work, and which parts are for getting distributed tracing across the queue boundary to work. They're different components.
  5. The queueing instrumentation setup of Spans isn't fully documented, and it isn't clear which of those values, e.g. messaging.destination.name are necessary for queue instrumentation, and which are optional.
    1. The full set of structured Extra values supported by the queue instrumentation isn't documented. Can't tell if the set in the code samples is exhaustive, or just representative.


There's some overlap in content with the above page an this page - https://docs.sentry.io/platforms/dotnet/tracing/trace-propagation/custom-instrumentation/

  1. On that page - This page's written documentation describes trace propagation via SentryHttpMessageHandler, but the code examples are all about manual trace propagation through message headers, so the words and the samples don't align on their topics.


https://docs.sentry.io/organization/integrations/source-code-mgmt/azure-devops/

  1. This page references the needs to create a personal access token as part of the setup of the Azure DevOps integration. But the integration doesn't actually authenticate any more through a PAT, it uses user OAuth now. I can confirm this, because I set the integration up under a newly-minted service account, and I never had to generate a PAT.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions