Error tracking - not showing the stacktrace correctly. File Unknown Source.

[moxplod]

I am using using posthog dotnet version 2.4.0

The stack trace for an exception when captured using CaptureException does not get the full stack trace.

It shows up as follows:

Microsoft.EntityFrameworkCore.DbUpdateConcurrencyException: The database operation was expected to affect 1 row(s), but actually affected 0 row(s); data may have been modified or deleted since entities were loaded. See https://go.microsoft.com/fwlink/?LinkId=527962 for information on understanding and handling optimistic concurrency exceptions.

File "Unknown Source", in: ThrowAggregateUpdateConcurrencyException

File "Unknown Source", in: MoveNext

File "Unknown Source", in: Throw

File "Unknown Source", in: ThrowForNonSuccess

File "Unknown Source", in: HandleNonSuccessAndDebuggerNotification

File "Unknown Source", in: Consume

File "Unknown Source", in: Execute

File "Unknown Source", in: Execute

File "Unknown Source", in: SaveChanges

File "Unknown Source", in: SaveChanges

File "Unknown Source", in: SaveChanges

File "Unknown Source", in: <Execute>b__0

File "Unknown Source", in: ExecuteImplementation

File "Unknown Source", in: Execute

File "Unknown Source", in: SaveChanges

File "PersonProfileWriteService.cs", line: 404, in: Merge

File "PersonProfileWriteService.cs", line: 326, in: Merge

File "PersonProfileWriteService.cs", line: 41, in: Upsert

[marandaneto]

cc @PostHog/team-error-tracking something to be looked at

[cat-ph]

we need to implement PDB uploading & symbolication for this to work properly I believe, if we get PDBs uploaded through a similar flow as the symbolsets one that we use for other SDKs, we should be able to resolve those back to files/lines (and can get source code context too if we embed the source optionally too)

[marandaneto]

we need to implement PDB uploading & symbolication for this to work properly I believe, if we get PDBs uploaded through a similar flow as the symbolsets one that we use for other SDKs, we should be able to resolve those back to files/lines (and can get source code context too if we embed the source optionally too)

yeah usually file names and line numbers require PDB support
this is not listed here as a limitation so thats surprising

@cat-ph so i'd at least add this info to the docs which makes error tracking much less useful

[cat-ph]

yep good point! added to docs in PostHog/posthog.com#17466 - planning to add native support in cymbal for rust, it should make it easier to add PDBs and implement this afterwards