Add Flutter --include-sources for Dart stack context - #780
Conversation
Pack DWARF-referenced .dart files into sources.srcbundle beside each .dartmap so symbolicated Flutter frames can show code snippets, matching the Apple/Android upload path. Co-authored-by: Cursor <cursoragent@cursor.com>
| // Lane copy, which the backend re-presigns so it can overwrite. | ||
| // No digests: every key here is either the dartmap's own build id, a Version | ||
| // Lane copy, or a source bundle that borrows that id — which the backend | ||
| // re-presigns so it can overwrite. |
There was a problem hiding this comment.
Source bundles lack upload digests
Medium Severity
uploadFlutterSymbols always passes a nil digests slice, including for sources.srcbundle objects under the Id lane. Those keys borrow the build id and do not prove bundle contents, so with default skipExisting an existing incomplete bundle is treated as already uploaded and never replaced. Apple and Android both send digests for the same “sources beside an id-keyed map” case so a later --source-path repair can overwrite.
Reviewed by Cursor Bugbot for commit b1d8f8c. Configure here.
Dart names a compilation unit by its script URI, so what a .dartmap stores as a frame's file is usually "package:my_app/main.dart", "dart:async", or "org-dartlang-sdk:///...", not a path. os.ReadFile cannot open any of those, so --include-sources shipped an empty bundle for a real build, and the basename fallback would answer "package:flutter/src/material/ink_well.dart" with whatever local file shared its name — the wrong code behind a real frame. Package URIs now resolve through the project's pubspec name to lib/, file URIs have their scheme stripped, and the SDK and every dependency are excluded rather than guessed at. Bundle keys stay the URI the map spells, which is what the backend looks a frame up by. Co-authored-by: Cursor <cursoragent@cursor.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.
There are 3 total unresolved issues (including 1 from previous review).
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 11f3436. Configure here.
| } | ||
| if alt := resolveFlutterSourceFallback(resolved, byBase); alt != "" { | ||
| return alt, true | ||
| } |
There was a problem hiding this comment.
Fallback loses relative path matches
Medium Severity
flutterSourceFile now calls resolveFlutterSourceFallback with the absolute resolved path instead of the DWARF key. With modern Flutter --resolve-dwarf-paths, in-project files are often stored as relative keys like lib/.../utils.dart while resolved is the build-machine absolute path. When several local files share a basename, the suffix check against that absolute path cannot match the checkout, so those sources are silently dropped.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 11f3436. Configure here.
| if strings.HasPrefix(rest, "/") { | ||
| return rest | ||
| } | ||
| return file |
There was a problem hiding this comment.
Windows file URIs stay unreadable
Medium Severity
resolveSourcePath strips file:// and returns the remainder whenever it starts with /. For Windows URIs like file:///C:/Users/..., that yields /C:/Users/..., which os.Stat rejects on Windows. Local sources that exist on the upload machine are treated as missing unless basename fallback happens to recover them.
Reviewed by Cursor Bugbot for commit 11f3436. Configure here.


Summary
.symbols→.dartmap.--include-sources/--source-pathsupport for--type flutter, uploadingsources.srcbundlebeside each map.--source-pathwhen DWARF absolute paths are unreadable on the upload machine.Test plan
go test ./cmd/symbols/ ./internal/symbols/flutter/ldcli symbols generate --type flutter --path <symbols> --out /tmp/out --include-sources --source-path <app>and confirmsources.srcbundlekeys beside.dartmap_sym/flutter/id/<id>/sources.srcbundleMade with Cursor