It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

For the tests its a bit difficult, as this is a production only bug. while in debug/test this case is illegal due to asserts.

Nice catch! Although I'm not sure this is meant to be fixed. As far as I can tell this error only happens when a zero duration is specified, and the DrivenScrollActivity actually asserts that duration cannot be zero. If this happens with duration other than zero, then this definitely needs a fix though.

This error occurs because AnimationController is smart, and when it's given a zero duration it won't start a ticker, but will simply invoke the tick callback immediately (and synchronously).

With that said, there is some space for improvement. We could check if the duration is zero and jump to the target immediately, like so:

--- a/packages/flutter/lib/src/widgets/scroll_position_with_single_context.dart
+++ b/packages/flutter/lib/src/widgets/scroll_position_with_single_context.dart
@@ -176,7 +176,7 @@ class ScrollPositionWithSingleContext extends ScrollPosition implements ScrollAc
 
   @override
   Future<void> animateTo(double to, {required Duration duration, required Curve curve}) {
-    if (nearEqual(to, pixels, physics.toleranceFor(this).distance)) {
+    if (nearEqual(to, pixels, physics.toleranceFor(this).distance) || duration == Duration.zero) {
       // Skip the animation, go straight to the position as we are already close.
       jumpTo(to);
       return Future<void>.value();

Here's a minimal reproducible code sample for this error. To trigger it, you have to start it in profile or release mode to disable asserts.

import 'package:flutter/material.dart';

void main() => runApp(const ExampleApp());

class ExampleApp extends StatelessWidget {
  const ExampleApp({super.key});

  @override
  Widget build(final BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        floatingActionButton: Builder(
          builder: (final BuildContext context) => FloatingActionButton(
            onPressed: () {
              const double targetOffset = 500.0;
              PrimaryScrollController.of(context).animateTo(
                targetOffset,
                duration: Duration.zero,
                curve: Curves.easeInOut,
              );
            },
          ),
        ),
        body: ListView.builder(
          primary: true,
          itemBuilder: (_, final int index) {
            final int shade = ((index % 9) + 1) * 100;
            return Container(height: 100, color: Colors.red[shade]!);
          },
        ),
      ),
    );
  }
}

This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@kszczek we can definetly jump directly to target and skip the animation.
🤔 it still seems reasonable to to first initialise the _controller before firing animateWith.

Hey @agrapine thanks for contributing! It looks like the is an analyzer failure, and we're missing some tests to verify this change works as expected. Is there an open issue this is looking to resolve? Right now it is hard to say if this is the right fix without more context. Thanks!

i can't find a good doc on how to fix the analyzer issue. sorry (already spent a bit too much time on this)

i can't find a good doc on how to fix the analyzer issue. sorry (already spent a bit too much time on this)

Documentation about debugging tests and how to contribute are in all in the repo under docs/.

(already spent a bit too much time on this)

I understand. Thanks for taking the time you did. Does this mean this PR should be closed? It still needs a test in addition to resolving the current failure.