Fix Flutter Errors from Sentry Alerts

The agent reads the alert payload after the prompt, then opens the issue and its latest event through the Sentry connection. A Flutter event carries the Dart exception type and message, frames with the file under lib/ and the line, the device and OS tags, and the breadcrumbs the app recorded before the crash. It keeps the frame's file and line and the breadcrumb trail as the two facts the test must reproduce: which widget or provider threw, and what the user had done just before.

Then it reads the app. In an app shaped like simplezhli/flutter_deer, pubspec.yaml names flutter_deer 1.3.3+22 with sdk: ">=3.4.0 <4.0.0", provider ^6.1.2, fluro ^2.0.5, dio ^5.9.0, rxdart, sp_util and cached_network_image, and the workflow in .github/workflows/flutter-drive.yml pins Flutter 3.47.4. Errors already flow through one place: lib/util/handle_error_utils.dart wraps runApp in runZonedGuarded, redirects FlutterError.onError into the zone in production, and leaves a _reportError function whose production branch is a comment saying to upload the error, which is where a Sentry SDK call lives in a real app. The network layer is lib/net/dio_utils.dart, which builds a Dio with ResponseType.plain, accepts every status with validateStatus and leaves status handling to AdapterInterceptor in lib/net/intercept.dart, and lib/net/error_handle.dart, whose ExceptionHandle.handleException maps a DioException to codes 1000 to 1007 and anything else to 9999 through _errorMap. Screens are grouped by module under lib/ with a page, provider and sometimes presenter directory each; list screens extend BaseListProvider<T> from lib/order/provider/base_list_provider.dart, which calls notifyListeners() on every mutation, and presenters such as lib/order/presenter/order_search_presenter.dart fill the provider from requestNetwork callbacks, setting hasMore from data.items!.length == 30.

The agent matches the frame to one of those files and picks the test shape the repository already uses. A crash inside a widget gets a widget test in the style of test/login/login_accessibility_test.dart, which pumps MyApp(home: page, theme: ThemeProvider().getTheme()) so routes, theme and localisation are real, then drives the breadcrumb trail with tester.tap and tester.enterText on the Keys the pages already carry, such as phone, vcode and password in the register page. A crash in a presenter or in the error mapping gets a plain test case, with Dio given a fake HttpClientAdapter that returns the body or status the breadcrumbs show, because the one network test the repository has, test/net/dio_test.dart, calls api.github.com for real and cannot run offline. Either way the test fails with the same exception and message as the event before any fix is made.

The fix goes to the one widget, provider, presenter or mapping at fault: a null check before a bang on a nullable model field, a mounted check before a context use after an await, a _errorMap entry for a DioExceptionType the extension maps to a code with no entry, a guard around data.items!. Then flutter pub get regenerates DeerLocalizations as l10n.yaml directs, flutter analyze runs under analysis_options.yaml with strict-casts, strict-inference and strict-raw-types, and flutter test runs the suite, with the network test named as skipped. The pull request quotes the event, the failing test output and the passing analyze and test output.

What comes back is a pull request that changes one file under lib/ and adds one test under test/, placed in the module directory the suite already uses, such as test/order/ or test/net/. Its description links the Sentry issue, quotes the exception and the frames, shows the test failing before the change and passing after, and gives the flutter analyze and flutter test output with the Flutter version used and the network test named as not run. pubspec.yaml does not change.

Before merging, a reviewer checks that the test drives the breadcrumb trail rather than calling the throwing method directly, so the fix is proven at the level the user hit it; that a null check does not silently blank a screen the user expected to be filled; and that the analyzer passed under the strict settings, which the quoted output shows. If the event came from a release older than the branch and the line has moved, the description says so and the test pins the current behaviour.

Create an alert rule in the Sentry project for the app with a webhook action pointed at a handler on your server. Sentry signs its own requests and cannot add the Authorization: Bearer header a Rush webhook trigger requires, so the handler receives the alert, places its JSON after the prompt and sends this request with the Sentry issue id as Idempotency-Key, which makes a redelivery return the run already started.

Set a webhook_url on the API key and Rush POSTs run.completed with the session_url when the turn ends, so the handler can read the pull request link and post it on the issue. A mobile crash arrives from many devices and Sentry folds them into one issue, so one issue is one run, and the handler can skip issues that already have an open pull request.

A Flutter crash depends on a screen, a theme, a locale and a sequence of taps, and reproducing it by hand means a simulator and a guess. The sandbox pumps the real MyApp with the real theme in a widget test, drives the breadcrumb steps through the widget keys, and runs the strict analyzer and the suite with the pinned Flutter version, keeping every command's output on the session.

The pull request carries its own proof: the event the agent read, the test failing with that exception and passing after the change, and the analyze and test output a reviewer can check line by line. Several alerts become several sandboxes, and the reviewer judges a one-file diff instead of a stack trace.

The repository has no Sentry SDK. Where does the event come from?

Does it need a device or simulator?

How does it test code that calls the network?

Will it change the error handling in handle_error_utils.dart?

Which Flutter version does it use?