getsentry
Source Context for internal projects not showing
Package
Sentry.AspNetCore
.NET Flavor
.NET
.NET Version
8.0.0
OS
Linux
SDK Version
4.9.0
Self-Hosted Sentry Version
No response
Steps to Reproduce
The project is configured like this:
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<!-- Configure Sentry org and project -->
<SentryOrg>…</SentryOrg>
<SentryProject>…</SentryProject>
<!-- Sends symbols to Sentry, enabling symbolication of stack traces. -->
<SentryUploadSymbols>true</SentryUploadSymbols>
<!-- Sends sources to Sentry, enabling display of source context. -->
<SentryUploadSources>true</SentryUploadSources>
</PropertyGroup>
This is the log that runs after dotnet publish…
Preparing upload to Sentry for project 'Services' (Release/net8.0): collecting debug symbols and referenced source code from bin/Release/net8.0/
> Found 49 debug information files (48 with embedded sources)
> Resolved source code for 0 debug information files
> Prepared debug information files for upload
> Uploaded 4 missing debug information files
> File upload complete:
According to the debug-symbols page in Sentry, the sources have been uploaded:
Expected Result
I'm expecting to see our source code shown, like it does for the Microsoft dll.
Actual Result
I don't know if there's a way to link to an issue so you can see behind the scenes, if there is, let me know.
I dropped you an email 👍🏻
On July 31, 2024, GitHub @.***> wrote:
Hey @lxalln https://github.com/lxalln, could you share the link to the issue with me? @.*** @.***> Thanks!
— Reply to this email directly, view it on GitHub <https://github.com/getsentry/sentry-dotnet/issues/3512#issuecomment- 2260692935>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/AAVHFVCIEA2CPOHXFDXKGV3ZPDZ6BAVCNFSM6AAAAABLYMVAFCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRQGY4TEOJTGU>. You are receiving this because you were mentioned.Message ID: @.***>
Thanks! There does seem to be something off. We're looking into it and will get back to you.
It looks like something is misconfigured here. Sentry attempts to pull the source contexts but encounters a 403 while doing so.
This is related to https://github.com/getsentry/symbolicator/pull/1507 which will help communicate that properly.
Closing this with the changes introduced in https://github.com/getsentry/symbolicator/pull/1507 should help with configuration. Please feel free to reopen this if the issue persists for you.
@bitsandfoxes the recent updates have made no difference to this, I'm not seeing any errors when uploading sources, is this something I should be seeing?
The mis-configuration you mentioned is that on our side?
It looks to me like like there's a conflict between Source Link and the uploaded sources. If you go into the actual json payload you can see each individual frame in the stacktrace having a source link attached to it. Sentry fails to retrieve the sources for your InApp frames (that's the 403 mentioned above).
What I don't get (yet) is why it's not falling back to the uploaded sources. Or why there is no error message detailing how to fix this.
Affects me as well.
I have noticed that builder.WebHost.UseSentry fails to set release to assembly version from AssemblyInformationalVersionAttribute. This is why I set release explicitly to "1.0.0+commit_sha", otherwise it sets it to "1.0.0.0".
Related: https://github.com/getsentry/sentry-dotnet/issues/3536
On the screenshot you can see Assembly version "1.0.0.0" as well, however release was created with "1.0.0+commit_sha" name, and source and debug files were uploaded to that release as well.
Release is created in CI/CD and there as well it fails to set release to assembly version from the attribute. In the CI/CD pipeline (bitbucket) we explicitly set release name as export SENTRY_RELEASE="1.0.0+${BITBUCKET_COMMIT}", otherwise once again it sets release to "1.0.0.0".
The project does not explicitly sets assembly version. There is no AssemblyVersion attribute manually set anywhere and csproj file does not have AssemblyVersion nor Version properties. net8.0.
OTel is not used (was used once, but removed, with nuget packages). Logging is default from ASP.NET Core.
string version = Assembly.GetEntryAssembly()?.GetNameAndVersion().Version ?? "1.0.0+unknown";
builder.WebHost.UseSentry(options =>
{
options.Release = version;
});
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<RuntimeIdentifier>linux-x64</RuntimeIdentifier>
...
</PropertyGroup>
<ItemGroup>
...
<PackageReference Include="Sentry.AspNetCore" Version="5.3.0" />
...
</ItemGroup>
<PropertyGroup Condition="'$(Configuration)' == 'Release' And '$(SENTRY_CREATE_RELEASE)' == 'true'">
<SentryOrg> [REDACTED] </SentryOrg>
<SentryProject> [REDACTED] </SentryProject>
<SentryCreateRelease>true</SentryCreateRelease>
<SentrySetCommits>true</SentrySetCommits>
<SentryUploadSymbols>true</SentryUploadSymbols>
<SentryUploadSources>true</SentryUploadSources>
</PropertyGroup>
could you folks please share a link to the issue in Sentry? or attach the json you can download from the issue details page so we can look closer?
cc @vaind maybe u know what's up
@bruno-garcia https://greatlab.sentry.io/issues/33365238/
Any issue in the project (or other dotnet projects) has the same problem.
@bruno-garcia https://koan-adventures.sentry.io/issues/6364382458/ Or any issues in our account, they're all broken.
https://github.com/getsentry/symbolicator/pull/1507
@loewenheim since this PR was yours, do you know what could be happening here if it's related?
I have noticed that builder.WebHost.UseSentry fails to set release to assembly version from AssemblyInformationalVersionAttribute. This is why I set release explicitly to "1.0.0+commit_sha", otherwise it sets it to "1.0.0.0".
Release name doesnt' affect looking up sources. That's done by debug_id which is what we use to find PDBs or source bundles.
@bruno-garcia koan-adventures.sentry.io/issues/6364382458 Or any issues in our account, they're all broken.
In your case it seems it's failing to fetch the source repository (it ways Permission) if you open Images Loaded in the link you sent. But the pdb you uploaded to Sentry does have sources.
@loewenheim should symbolicator be able to fetch the sources then from the pdb then? If it knows it has sources?
@bruno-garcia greatlab.sentry.io/issues/33365238 Any issue in the project (or other dotnet projects) has the same problem.
This clearly has sources too, and doesn't have any permission issue under Loaded Images:
@loewenheim seems like a bug?
Looking at frame 19 (which is the first in-app frame, with line number 521) in this event:
- The frame's abs path is
/opt/atlassian/pipelines/agent/build/Greatlab.Service/DoctorService.cs. - The portable PDB file for the frame contains sources, but not the one with that path. The sources it contains are
-
/opt/atlassian/pipelines/agent/build/Greatlab.Service/obj/Release/net8.0/Greatlab.Service.GlobalUsings.g.cs -
/opt/atlassian/pipelines/agent/build/Greatlab.Service/obj/Release/net8.0/.NETCoreApp,Version=v8.0.AssemblyAttributes.cs -
/opt/atlassian/pipelines/agent/build/Greatlab.Service/obj/Release/net8.0/Sentry.Attributes.cs -
/opt/atlassian/pipelines/agent/build/Greatlab.Service/obj/Release/net8.0/Greatlab.Service.AssemblyInfo.cs
-
- The file does, however, contain a source link for the file in question, which points to bitbucket.
- Symbolicator fails to download the file from bitbucket for permission reasons.
From my perspective this doesn't look like a bug, unless I've misunderstood something. I see how it's confusing though that the portable PDB says it contains sources but doesn't actually contain the one(s) you need.
Symbolicator fails to download the file from bitbucket for permission reasons
If permissions are the case, then this is confusing for me as a user, because we have integration with BitBucket for the required repository, and it says that "Link your Sentry stack traces back" feature is enabled.
Also, I have expected if BitBucket fails, then embedded sources should kick in.
If permissions are the case, then this is confusing for me as a user, because we have integration with BitBucket for the required repository, and it says that "Link your Sentry stack traces back" feature is enabled.
That is not exactly what this feature is meant for, see https://docs.sentry.io/organization/integrations/source-code-mgmt/bitbucket/#stack-trace-linking. However, it is definitely an unfortunate limitation that Symbolicator (the service that symbolicates and resolves source context) doesn't know your bitbucket credentials, even though Sentry has them. That is something we need to improve.
Also, I have expected if BitBucket fails, then embedded sources should kick in.
In the example I looked at, there are no embedded sources (well, there are four files, but none of them show up in the stacktrace, so they're irrelevant). To me it looks like your sources (at least, the ones you care about) are not being included in the portable PDB file at all, but I don't know if this is something you have any control over.
https://github.com/getsentry/symbolicator/issues/1666 is the tracking issue for improving the situation around source code hosting.
@bruno-garcia koan-adventures.sentry.io/issues/6364382458 Or any issues in our account, they're all broken.
In your case it seems it's failing to fetch the source repository (it ways
Permission) if you openImages Loadedin the link you sent. But the pdb you uploaded to Sentry does have sources. @loewenheim should symbolicator be able to fetch the sources then from the pdb then? If it knows it has sources?
Is there anything more I can do about this? From what I can see, I've followed the instructions required to get this feature to work, I'm not sure why there is a permission problem, isn't everyone going to have that problem (unless it's a public repo)?
Is there anything more I can do about this? From what I can see, I've followed the instructions required to get this feature to work, I'm not sure why there is a permission problem, isn't everyone going to have that problem (unless it's a public repo)?
Yes, unfortunately this is a general problem. The expected use case was that users would upload their sources to Sentry and that sources that weren't uploaded would be publicly accessible, but it's clearly not working out that way.
From the issue history above, it looks like this issue will be addressed in the symbolicator:
- https://github.com/getsentry/symbolicator/issues/1666
I'll remove the "Bug" label for the issue in this repository but keep the issue here in case other people run into the same problem.
