fix(maestro): use a portable mktemp template in run_maestro

`mktemp -t maestro-run` works on BSD/macOS, which appends the random suffix
itself, but GNU coreutils requires at least 6 X's in the template. So on the
Linux Android runners every flow printed

  mktemp: too few X's in template 'maestro-run'
  '': No such file or directory (os error 2)

— log_file was empty, so the tee redirection failed and maestro never ran.
iOS was unaffected, which is why this passed local and macOS testing.

Use an explicit XXXXXX template, which both implementations accept, and fall
back to a PID-based path if mktemp fails for any other reason: artifact
plumbing must never be what decides whether the tests run.

Audited the rest of the commands added in this series (tr -c, grep -qE) —
both POSIX, and already used by the pre-existing recording code that runs on
Android.

Verified by stubbing a GNU-strict mktemp on PATH: reproduces the CI error with
the old form and run_maestro completes with the new one.

fix(intro-screen-native): catch the trailing drag whatever order it arrives in

The Android e2e flow failed deterministically (both the first attempt and the
retry) at `Assert that "Active slide: 3" is visible`. The CI video shows the
widget reach slide 3, then snap back to slide 1 and increment the change
counter, so the trailing drag the previous guard was written for still got
through.

It got through because the guard required evidence that a programmatic scroll
had landed (settledScrollTarget), and that evidence is not always recorded: the
settling list can emit its trailing scrollBeginDrag BEFORE the scroll's own
momentum end, and onScrollBeginDrag clears the pending target, so the branch
that would have set settledScrollTarget never runs. The guard was then skipped
and the stale offset was treated as a swipe.

Drop the bookkeeping and rely on the geometry instead. The list is
pagingEnabled, so a drag settles at most one page from where it began; a
momentum end further away than that cannot be a finger regardless of what came
before it. Covered by a test reproducing the CI ordering, which fails without
the change.

Author: YogendraShelke

maestro/helpers/helpers.sh

@@ -159,7 +159,17 @@ run_maestro() {
   local flow="$1"
   shift
   local log_file
-  log_file="$(mktemp -t maestro-run)"
+  # Explicit XXXXXX template, not `mktemp -t maestro-run`: BSD/macOS mktemp appends the random
+  # suffix itself, but GNU coreutils (the Linux Android runners) requires at least 6 X's in the
+  # template and fails with "too few X's in template", leaving log_file empty and every
+  # redirection to it failing. Works on both.
+  log_file="$(mktemp "${TMPDIR:-/tmp}/maestro-run.XXXXXX")" || log_file=""
+  if [ -z "$log_file" ]; then
+    # Never let artifact plumbing decide whether tests run: fall back to a fixed path so the
+    # flow still executes (classification just loses its input if that also fails).
+    log_file="${TMPDIR:-/tmp}/maestro-run.$$"
+    : > "$log_file" 2>/dev/null || true
+  fi
 
   DEBUG_RUN_DIR="$DEBUG_OUTPUT_DIR/${PLATFORM}-$(basename "${flow%.yaml}" | tr -c 'A-Za-z0-9._-' '_')"
   rm -rf "$DEBUG_RUN_DIR"

packages/pluggableWidgets/intro-screen-native/src/SwipeableContainer.tsx

@@ -80,10 +80,6 @@ export const SwipeableContainer = (props: SwipeableContainerProps): ReactElement
     // wherever the user left it. Used to recognise momentum events that contradict the
     // scroll we just asked for; see onMomentumScrollEnd.
     const pendingScrollTarget = useRef<number | null>(null);
-    // Slide the last programmatic scroll settled on. Android can follow that scroll with a
-    // second drag+momentum pair reporting the offset the list LEFT, which looks exactly like
-    // a user swipe back; see onMomentumScrollEnd.
-    const settledScrollTarget = useRef<number | null>(null);
 
     const rtlSafeIndex = useCallback(
         (i: number): number => (isAndroidRTL ? props.slides.length - 1 - i : i),
@@ -95,7 +91,6 @@ export const SwipeableContainer = (props: SwipeableContainerProps): ReactElement
             setActiveIndex(pageNum);
             if (flashList && flashList.current) {
                 pendingScrollTarget.current = pageNum;
-                settledScrollTarget.current = null;
                 flashList.current.scrollToOffset({
                     offset: rtlSafeIndex(pageNum) * width,
                     animated
@@ -360,10 +355,6 @@ export const SwipeableContainer = (props: SwipeableContainerProps): ReactElement
             if (pendingTarget !== null) {
                 if (newIndex === pendingTarget) {
                     pendingScrollTarget.current = null;
-                    // Remember where the scroll landed: on Android the settling list can emit a
-                    // SECOND drag + momentum pair afterwards, and that one carries the offset it
-                    // moved away from.
-                    settledScrollTarget.current = pendingTarget;
                 }
                 return;
             }
@@ -372,14 +363,18 @@ export const SwipeableContainer = (props: SwipeableContainerProps): ReactElement
                 return;
             }
 
-            // The list is pagingEnabled, so one drag moves exactly one page. A momentum end that
-            // jumps more than a page right after a programmatic scroll settled is therefore the
-            // tail of that scroll, reporting the offset it moved AWAY from — not a swipe. Android
-            // emits it with the drag flag set (the settling list, not a finger, starts the drag),
-            // so wasUserDragging cannot tell the two apart, and trusting it rewrote the attribute
-            // to the slide being left: pressing NEXT on slide 2 wrote 3, then 1. A one-page swipe
-            // still reports normally.
-            if (settledScrollTarget.current !== null && Math.abs(newIndex - activeIndex) > 1) {
+            // The list is pagingEnabled, so a drag settles at most one page from where it began.
+            // Any momentum end further away than that is the tail of a programmatic scroll,
+            // reporting an offset the list has already left — not a swipe. Android emits it with
+            // the drag flag set (the settling list, not a finger, begins the drag), so
+            // wasUserDragging cannot tell the two apart, and trusting it rewrote the attribute to
+            // a slide that is not on screen: pressing NEXT on slide 2 wrote 3, then 1.
+            //
+            // This deliberately does not depend on having seen the programmatic scroll land. That
+            // trailing drag can arrive BEFORE the scroll's own momentum end, and onScrollBeginDrag
+            // clears pendingScrollTarget, so there is no record left to gate on — the earlier
+            // version of this guard checked for one and was skipped in exactly that ordering.
+            if (Math.abs(newIndex - activeIndex) > 1) {
                 return;
             }
 

packages/pluggableWidgets/intro-screen-native/src/__tests__/SwipeableContainer.remount.spec.tsx

@@ -221,17 +221,43 @@ describe("SwipeableContainer remount behaviour", () => {
         fireEvent.press(getByTestId("intro$buttonNext"));
         onSlideChange.mockClear();
 
-        // The user grabs the list before the scroll to slide 3 settles and swipes back to
-        // slide 1. Taking over invalidates the pending target, so this must be reported.
+        // The user grabs the list before the scroll to slide 3 settles and swipes back one
+        // page, landing on slide 2. Taking over invalidates the pending target, so this must
+        // be reported even though the scroll it interrupted never reported a momentum end.
+        act(() => {
+            fireEvent(getByTestId("intro"), "scrollBeginDrag", {});
+            fireEvent(getByTestId("intro"), "momentumScrollEnd", {
+                nativeEvent: { contentOffset: { x: WIDTH } }
+            });
+        });
+
+        expect(onSlideChange).toHaveBeenCalledWith(1, 2);
+        expect(activeSlide.setValue).toHaveBeenLastCalledWith(new Big(2));
+    });
+
+    it("ignores a trailing drag that arrives before the programmatic scroll reports landing", () => {
+        // The ordering that defeated the previous guard, taken from the Android CI video: on the
+        // re-entered page NEXT moves slide 2 -> 3, and the settling list emits its trailing
+        // scrollBeginDrag BEFORE the scroll's own momentum end. That drag clears the pending
+        // target, so nothing records that a programmatic scroll ever landed — the old guard
+        // required such a record and was skipped, sending the attribute 3 -> 1 and reporting a
+        // change, which is what the flow's "Active slide: 3" assertion saw as "Active slide: 1".
+        const { getByTestId, activeSlide, onSlideChange } = setup(2);
+
+        fireEvent.press(getByTestId("intro$buttonNext"));
+        expect(activeSlide.setValue).toHaveBeenLastCalledWith(new Big(3));
+
         act(() => {
             fireEvent(getByTestId("intro"), "scrollBeginDrag", {});
             fireEvent(getByTestId("intro"), "momentumScrollEnd", {
                 nativeEvent: { contentOffset: { x: 0 } }
             });
         });
 
-        expect(onSlideChange).toHaveBeenCalledWith(0, 2);
-        expect(activeSlide.setValue).toHaveBeenLastCalledWith(new Big(1));
+        expect(activeSlide.setValue).toHaveBeenLastCalledWith(new Big(3));
+        expect(onSlideChange).toHaveBeenCalledTimes(1);
+        expect(onSlideChange).toHaveBeenCalledWith(2, 1);
+        expect(getByTestId("intro$buttonDone")).toBeTruthy();
     });
 
     it("ignores a stale programmatic scroll that reports the pre-scroll offset", () => {