fix(intro-screen-native): ignore the trailing drag a settled scroll emits

The Android IntroScreen flow failed at its last assertion: after re-entering
the page, NEXT moved slide 2 -> 3 and the attribute correctly became 3, then
immediately flipped to 1, so "Active slide: 3" was never visible. The failure
video shows the value on screen going 2 -> 3 -> 1 with no input in between.

Cause: once the programmatic scroll to slide 3 settles, Android's list emits a
SECOND onScrollBeginDrag + onMomentumScrollEnd pair, and that momentum event
carries the offset the list moved AWAY from (0). The existing pendingScrollTarget
guard had already been cleared by the first, legitimate momentum end, and
wasUserDragging was true because the settling list — not a finger — began the
drag. So the event was treated as a swipe back to slide 1 and rewrote the
attribute. This is the same class of bug as the earlier phantom-momentum fix,
one step later in the sequence.

Fix: remember the slide a programmatic scroll settled on, and ignore a momentum
end that moves more than one page from activeIndex while that memory is set.
The list is pagingEnabled, so a genuine drag moves exactly one page; a
multi-page jump right after a scroll settled can only be that scroll's tail.
One-page swipes, including a swipe straight after a programmatic scroll, still
report normally (covered by existing tests).

Regression test added; it fails with setValue receiving [3, 1] and a spurious
onSlideChange(0, 2) when the guard is removed.

Revert "fix(e2e): scroll the alphabet-index target into view before tapping it"

This reverts commit 31e9fd78c2fb70fb0e88b33b2d9bf8a983c4db51.

fix(e2e): scroll the alphabet-index target into view before tapping it

FloatingActionButton.yaml failed on iOS with

  Tap on "F"... COMPLETED
  Assert that "Floating action button" is visible... FAILED

then passed on retry with the same build. The flow already had the 10s
extendedWaitUntil added in 20d3d52, and that wait is what timed out — so
this is not the render race that commit fixed; nothing was going to change in
second 11 and a longer timeout would not have helped.

extendedWaitUntil: visible requires the element to be IN THE VIEWPORT, not
merely present in the hierarchy. Tapping the index scrolls to the letter's
section, and under F the entries are Feedback then Floating action button; if
the scroll settles with Feedback at the bottom edge, the target is rendered
just below the fold and `visible` stays false forever. The retry's scroll
landed a few pixels differently and it passed.

Use scrollUntilVisible instead: it succeeds immediately when the element is
already in view and scrolls to it when it is not, so it covers both the
original render race and the off-screen case. centerElement keeps the
subsequent tap away from the screen edge.

Applied to the 55 flows whose index letter hosts more than one widget entry
(B, C, F, I, L, P, R, S) — the case where the target can be pushed below the
fold. The 16 flows on a sole-entry letter keep the cheaper wait.

Verified: all 82 flows still parse, all 71 index taps remain guarded (55
scrollUntilVisible + 16 extendedWaitUntil, 0 unguarded), and the pinned 2.6.1
binary accepts every field used — confirmed it rejects an unknown property, so
that parse is a real schema check.

ci(e2e): archive maestro's debug output for failed flows

Maestro writes a debug bundle per run — failure screenshot, maestro.log
(which records the element Bounds each selector matched) and
commands-<flow>.json — to ~/.maestro/tests/<timestamp>/. That is outside the
workspace, so none of it was ever uploaded, and it is exactly what
distinguishes "element never rendered" from "element rendered off-screen
below the fold" when an assertVisible/extendedWaitUntil fails. Without it
those failures can only be diagnosed by inference.

Redirect it into the workspace with --debug-output (+ --flatten-debug-output,
which its own help text recommends for CI) one dir per flow, and archive it.
Kept only for FAILED flows, mirroring the existing video policy, so a green
shard uploads nothing — each bundle is ~300KB.

Also gitignore maestro/debug and maestro/videos: both are produced into the
workspace by local runs too. The existing *.log rule covered maestro.log but
not the bundle's screenshots or commands JSON.

Verified --debug-output and --flatten-debug-output against the pinned 2.6.1
binary, and drove run_tests with a stub to confirm a failing flow's bundle is
kept while a passing flow's is discarded.

fix(maestro): recover from iOS driver/accessibility faults instead of hanging

A shard could die with, and never recover from:

  Exception in thread "main" UnknownFailure(errorResponse=Request for
  viewHierarchy failed, code: 500, body: {"errorMessage":"Error getting
  element frame kAXErrorInvalidUIElement","code":"internal"})

Traced through the pinned 2.6.1 jars, this is unrecoverable by design.
XCTestDriverClient.handleExceptions maps a 500 to a typed error only for
four known message strings and otherwise throws UnknownFailure;
XCTestIOSDevice.execute catches only AppCrash/OperationTimeout/Unreachable,
and IOSDriver.runDeviceCall catches only the matching IOSDeviceErrors.
UnknownFailure matches none, so it escapes to main — hence "Exception in
thread main" rather than a failed step, and hence a flow-level `retry:`
block cannot help: the CLI is already dead, no command failed. kAXError*
means the accessibility element reference is stale, so every later query
against that driver fails identically.

Recovery therefore has to live in the shell. Add run_maestro(), which:

  - runs `maestro test` under a wall-clock watchdog (MAESTRO_FLOW_TIMEOUT,
    480s) so a JVM that died in main but is held open by non-daemon threads
    can't eat the 30-minute job budget, and
  - classifies a FAILED run as infrastructure (exit 90) when the output
    carries a driver/accessibility signature, so callers can tell "the
    device broke" from "the widget is wrong".

run_tests then resets the device and gives the flow one clean attempt with
a freshly reinstalled driver, instead of recording a widget failure and
marching every remaining flow through the same wedged driver. All three
call sites (flows, smoke check, retries) now go through run_maestro, and
the duplicated device-reset branches collapse into reset_device().

Only non-zero exits are reclassified, so a flow that passed after Maestro's
own internal retry logged such an error still counts as a pass.

fix(maestro): actually apply the iOS driver startup timeout

MAESTRO_DRIVER_STARTUP_TIMEOUT was passed to maestro as `--env`, but
LocalXCTestInstaller.getStartupTimeout() reads it with System.getenv() —
`--env` only fills Maestro's per-flow variable map, which that function
never consults. So every value we passed was silently ignored and the
Kotlin runCatching kept falling back to its built-in 120000 default.
Export it instead (and raise it to 240000), and drop the three no-op
`--env MAESTRO_DRIVER_STARTUP_TIMEOUT` arguments.

Also stop reinstalling the XCUITest driver once per flow. Maestro's
TestCommand.reinstallDriver defaults to true, so each `maestro test`
process runs restartXCTestRunner (uninstall + install + start) — and that
install is the window that throws IOSDriverTimeoutException on a 3-vCPU
macOS runner. The smoke check still installs the driver fresh at the start
of every shard and retries still reinstall via restart_simulator, so only
the first-pass flows reuse it. MAESTRO_REUSE_DRIVER=false restores the
old behaviour.

Author: YogendraShelke

.github/actions/archive-test-results/action.yaml

@@ -67,6 +67,21 @@ runs:
         path: packages/pluggableWidgets/**/artifacts/
         if-no-files-found: ignore
 
+    # Maestro's own debug bundle per FAILED flow: the failure screenshot, maestro.log (which
+    # records the element Bounds each selector matched) and commands-<flow>.json. This is what
+    # separates "element never rendered" from "element rendered off-screen below the fold" on
+    # an assertVisible/extendedWaitUntil failure. It defaults to ~/.maestro/tests/<timestamp>/,
+    # outside the workspace, so it was never uploaded and those failures had to be diagnosed by
+    # inference; helpers.sh now redirects it here with --debug-output and keeps only the
+    # failures' bundles, same policy as the videos below.
+    - name: Archive maestro debug output
+      uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f #v7
+      if: ${{ !cancelled() }}
+      with:
+        name: ${{ inputs.platform }}-debug-${{ inputs.test-type }}
+        path: ${{ inputs.workspace-path }}/maestro/debug/**
+        if-no-files-found: ignore
+
     # Per-flow videos are recorded for every flow but kept only for FAILED flows (passing
     # clips are deleted in helpers.sh to save storage), so on a fully-green shard this dir is
     # empty and the upload is a no-op (if-no-files-found: ignore).

.gitignore

@@ -20,6 +20,12 @@ mendixProject
 **/tests/testProject
 **/pluggableWidgets/**/artifacts
 
+# Per-flow e2e failure artifacts, produced into the workspace so CI can upload them
+# (helpers.sh). Local runs leave them behind too; they are never committed. *.log above
+# already covers maestro/debug/*/maestro.log, but not its screenshots or commands JSON.
+maestro/videos
+maestro/debug
+
 .pnpm-debug.log*
 .pnpm-store
 .pnpmfile.cjs

maestro/helpers/helpers.sh

@@ -10,7 +10,14 @@ RETRY_DELAY=10
 # CI emulators/simulators are slower, but 5 min (300000) was the per-attempt multiplier that
 # amplified broken-build runs to ~25 min. 2 min is generous for the driver to start while
 # keeping the worst-case failure time bounded.
-MAESTRO_DRIVER_STARTUP_TIMEOUT=120000
+#
+# MUST be `export`ed. Maestro reads this with System.getenv("MAESTRO_DRIVER_STARTUP_TIMEOUT")
+# (LocalXCTestInstaller.getStartupTimeout), i.e. from the PROCESS ENVIRONMENT — it is not a
+# flow variable. Passing it as `--env` only populates Maestro's per-flow variable map, which
+# getStartupTimeout never consults, so the parse failed and the Kotlin runCatching fell back
+# to its built-in 120000 default. Every `--env MAESTRO_DRIVER_STARTUP_TIMEOUT=...` we passed
+# was silently ignored; raising the number here had no effect until it became an env var.
+export MAESTRO_DRIVER_STARTUP_TIMEOUT=240000
 
 # --- Per-flow video recording (BrowserStack-style debugging) ----------------------------
 # We record a screen video around every flow, then KEEP it only if the flow FAILS and DELETE
@@ -78,6 +85,150 @@ stop_recording() {
   REC_FILE=""
 }
 
+# --- Driver/accessibility failure handling ----------------------------------------------
+#
+# Some iOS failures are NOT test failures — they are the XCUITest driver or the simulator's
+# accessibility server breaking, and Maestro cannot recover from them by design:
+#
+#   Error: Exception in thread "main" UnknownFailure(errorResponse=Request for viewHierarchy
+#   failed, code: 500, body: {"errorMessage":"Error getting element frame
+#   kAXErrorInvalidUIElement","code":"internal"})
+#
+# Traced through the pinned 2.6.1 jars: XCTestDriverClient.handleExceptions maps a 500 body to
+# a specific error only for four known strings ("Lost connection to the application…",
+# "Application … is not running", "Error getting main window…") and otherwise throws
+# XCUITestServerError$UnknownFailure. XCTestIOSDevice.execute catches only AppCrash /
+# OperationTimeout / Unreachable, and IOSDriver.runDeviceCall likewise catches only
+# IOSDeviceErrors Unreachable / AppCrash / OperationTimeout. UnknownFailure matches none of
+# them, so it propagates uncaught to main — which is why the message says "Exception in thread
+# main" rather than a failed step, and why a flow-level `retry:` block cannot catch it: the CLI
+# is already dead, no command failed. kAXError* means the accessibility element reference went
+# stale, so every subsequent query against that driver fails the same way.
+#
+# So recovery has to happen HERE, in the shell, on two axes:
+#   1. bound the wall clock, because a died-in-main JVM does not reliably exit (non-daemon
+#      threads keep it alive) and an unbounded hang eats the whole job timeout; and
+#   2. reset the DEVICE and retry, instead of recording it as a widget failure and marching
+#      the remaining flows through the same wedged driver.
+
+# Wall-clock cap for one `maestro test` invocation. A hang breaker, not a performance budget:
+# Precondition allows 60s × 3 attempts and the slowest widget flows add a couple of minutes on
+# a 3-vCPU runner, so a healthy flow stays well under this while a wedged driver is cut off.
+#
+# Sized against the widget-test jobs' timeout-minutes: 30 (NativePipeline.yml). At 480s a shard
+# survives ~2 hung flows and still has time to report and upload artifacts; the whole point is
+# that the shard fails with videos/logs attached instead of being killed by GitHub mid-upload,
+# which is what leaves you with no evidence at all.
+MAESTRO_FLOW_TIMEOUT="${MAESTRO_FLOW_TIMEOUT:-480}"
+
+# run_maestro returns this (rather than maestro's own exit code) when the run died from a
+# driver/accessibility fault or the watchdog had to kill it. 90 is outside the 0-1 range
+# maestro itself uses and below the 128+N signal range.
+MAESTRO_INFRA_EXIT=90
+
+# Signatures that mean "the device/driver broke", not "the widget is wrong". Deliberately
+# narrow: a real assertion failure prints "Assertion is false" and exits 1 through the normal
+# path, so it matches none of these.
+#   kAXError…                  accessibility server returned a stale/invalid element
+#   UnknownFailure             the unmapped-500 case above
+#   Exception in thread "main"  the CLI died instead of reporting a result
+#   IOSDriverTimeoutException  driver never came up
+#   Failed to connect …        driver port never opened
+MAESTRO_INFRA_PATTERNS='kAXError|UnknownFailure|Exception in thread "main"|IOSDriverTimeoutException|Failed to connect to 127\.0\.0\.1'
+
+# --- Per-flow debug output ---------------------------------------------------------------
+# Maestro writes a debug bundle per run to ~/.maestro/tests/<timestamp>/ containing the
+# failure screenshot, maestro.log (which records the element Bounds it matched against) and
+# commands-<flow>.json. That is exactly what distinguishes "element never rendered" from
+# "element rendered off-screen below the fold" on an `assertVisible`/`extendedWaitUntil`
+# failure — and it lived outside the workspace, so none of it was ever uploaded and every
+# such failure had to be diagnosed by inference.
+#
+# Redirect it into the workspace with --debug-output so it can be archived, one dir per flow
+# (--flatten-debug-output drops the per-run timestamp subdir, which is what its help text
+# recommends for CI). Kept only for FAILED flows, mirroring the video policy, since a green
+# shard's bundles are ~300KB × every flow of noise.
+DEBUG_OUTPUT_DIR="${DEBUG_OUTPUT_DIR:-$PWD/maestro/debug}"
+
+# run_maestro <yaml_or_flow> [extra maestro args...]
+#
+# Runs `maestro test` under a watchdog, streaming output live (CI needs to see progress) while
+# also capturing it so we can classify the failure afterwards. Sets DEBUG_RUN_DIR for the
+# caller, so a failing flow's debug bundle can be kept and a passing one's discarded.
+run_maestro() {
+  local flow="$1"
+  shift
+  local log_file
+  log_file="$(mktemp -t maestro-run)"
+
+  DEBUG_RUN_DIR="$DEBUG_OUTPUT_DIR/${PLATFORM}-$(basename "${flow%.yaml}" | tr -c 'A-Za-z0-9._-' '_')"
+  rm -rf "$DEBUG_RUN_DIR"
+  mkdir -p "$DEBUG_RUN_DIR"
+  set -- --debug-output "$DEBUG_RUN_DIR" --flatten-debug-output "$@"
+
+  # Process substitution rather than a `| tee` pipeline: with a pipeline $! is tee's PID and we
+  # would have no handle on the JVM to kill. maestro's bin script ends in `exec "$JAVACMD"`, so
+  # $! is the JVM itself. Its own children (XCTRunner, xcodebuild) can outlive the kill, but the
+  # infra path follows up with reset_device, which on iOS runs cleanup_xctest_processes and
+  # pkills exactly those.
+  "$HOME/.local/bin/maestro/bin/maestro" test "$@" \
+    --env APP_ID="$APP_ID" --env PLATFORM="$PLATFORM" "$flow" \
+    > >(tee "$log_file") 2>&1 &
+  local maestro_pid=$!
+
+  (
+    local waited=0
+    while [ "$waited" -lt "$MAESTRO_FLOW_TIMEOUT" ]; do
+      kill -0 "$maestro_pid" 2>/dev/null || exit 0
+      sleep 5
+      waited=$((waited + 5))
+    done
+    echo "::warning::maestro exceeded ${MAESTRO_FLOW_TIMEOUT}s on $(basename "$flow") — killing it (hung driver)"
+    kill -TERM "$maestro_pid" 2>/dev/null || true
+    sleep 10
+    kill -9 "$maestro_pid" 2>/dev/null || true
+  ) &
+  local watchdog_pid=$!
+
+  wait "$maestro_pid"
+  local status=$?
+  kill "$watchdog_pid" 2>/dev/null || true
+  wait "$watchdog_pid" 2>/dev/null || true
+
+  # Let tee drain before reading the log; it is reaped asynchronously from the substitution.
+  sleep 1
+
+  # Only reclassify a FAILED run: a flow that exited 0 passed, whatever its log happens to
+  # contain (Maestro logs a retried command's error inline, so a passing flow's output can
+  # legitimately mention a driver error it already recovered from).
+  # status >128 means the watchdog signalled it, i.e. it hung — infrastructure by definition.
+  if [ "$status" -ne 0 ] &&
+     { [ "$status" -gt 128 ] || grep -qE "$MAESTRO_INFRA_PATTERNS" "$log_file" 2>/dev/null; }; then
+    rm -f "$log_file"
+    return "$MAESTRO_INFRA_EXIT"
+  fi
+  rm -f "$log_file"
+  return "$status"
+}
+
+# Drop the last run's debug bundle. Called on pass so only failing flows' bundles survive to
+# be uploaded; a retry that passes also clears the earlier attempt's, matching the videos.
+discard_debug_output() {
+  [ -n "${DEBUG_RUN_DIR:-}" ] || return 0
+  rm -rf "$DEBUG_RUN_DIR"
+  DEBUG_RUN_DIR=""
+}
+
+# Reset the layer that actually flakes: on iOS restart the simulator (re-runs prepare_ios.sh,
+# re-establishing a clean XCUITest driver); on Android just re-confirm the emulator is up.
+reset_device() {
+  if [ "$PLATFORM" == "android" ]; then
+    ensure_emulator_ready
+  else
+    restart_simulator
+  fi
+}
+
 # Function to clean up stale XCTest processes (iOS only)
 cleanup_xctest_processes() {
     if [ "$PLATFORM" != "ios" ]; then
@@ -184,6 +335,26 @@ ensure_emulator_ready() {
     done
 }
 
+# Extra flags for the per-flow `maestro test` runs (NOT the smoke check, NOT retries).
+#
+# Maestro reinstalls the driver on EVERY invocation by default (TestCommand.reinstallDriver
+# defaults to true → XCTestDriverClient.restartXCTestRunner uninstalls, reinstalls, then
+# starts). Since each flow is its own `maestro test` process, a shard pays that full
+# uninstall+install+launch once per flow, and that install is exactly the window that throws
+# IOSDriverTimeoutException on a 3-vCPU macOS runner.
+#
+# The smoke check runs WITH reinstall, so every shard starts from a freshly installed driver
+# and the first-pass flows then reuse it. Every RECOVERY path deliberately omits this flag and
+# so reinstalls: the post-fault retry in run_tests, and rerun_failed_tests (which also calls
+# reset_device). That is the point — if the driver is what broke, reusing it is the last thing
+# we want. Set MAESTRO_REUSE_DRIVER=false to reinstall per flow everywhere.
+MAESTRO_REUSE_DRIVER="${MAESTRO_REUSE_DRIVER:-true}"
+flow_driver_args() {
+  if [ "$PLATFORM" == "ios" ] && [ "$MAESTRO_REUSE_DRIVER" = "true" ]; then
+    echo "--no-reinstall-driver"
+  fi
+}
+
 # Function to run tests
 run_tests() {
   local test_files=("$@")
@@ -194,10 +365,32 @@ run_tests() {
       set_status_bar
     fi
     start_recording "$(basename "${yaml_test_file%.yaml}")"
-    if $HOME/.local/bin/maestro/bin/maestro test --env APP_ID=$APP_ID --env PLATFORM=$PLATFORM --env MAESTRO_DRIVER_STARTUP_TIMEOUT=$MAESTRO_DRIVER_STARTUP_TIMEOUT "$yaml_test_file"; then
+    run_maestro "$yaml_test_file" $(flow_driver_args)
+    local status=$?
+    if [ "$status" -eq 0 ]; then
       echo "✅ Test passed: $yaml_test_file"
       stop_recording discard
+      discard_debug_output
       passed_tests+=("$yaml_test_file")
+    elif [ "$status" -eq "$MAESTRO_INFRA_EXIT" ]; then
+      # The driver/accessibility server broke rather than the widget misbehaving, so this run
+      # says nothing about the flow. Reset the device and give it ONE clean attempt right here,
+      # with a freshly installed driver (no --no-reinstall-driver), before deciding anything.
+      # Without this the wedged driver would fail this flow AND every flow after it.
+      echo "::warning::Driver/device fault on $(basename "$yaml_test_file") (not a test failure) — resetting device and retrying once"
+      stop_recording keep
+      reset_device
+      start_recording "$(basename "${yaml_test_file%.yaml}")"
+      if run_maestro "$yaml_test_file"; then
+        echo "✅ Test passed after device reset: $yaml_test_file"
+        stop_recording discard
+        discard_debug_output
+        passed_tests+=("$yaml_test_file")
+      else
+        echo "❌ Test failed: $yaml_test_file"
+        stop_recording keep
+        failed_tests+=("$yaml_test_file")
+      fi
     else
       echo "❌ Test failed: $yaml_test_file"
       stop_recording keep
@@ -228,22 +421,17 @@ smoke_check() {
       set_status_bar
     fi
     start_recording "smoke-attempt-$attempt"
-    if $HOME/.local/bin/maestro/bin/maestro test --env APP_ID=$APP_ID --env PLATFORM=$PLATFORM --env MAESTRO_DRIVER_STARTUP_TIMEOUT=$MAESTRO_DRIVER_STARTUP_TIMEOUT "$script_dir/Smoke.yaml"; then
+    if run_maestro "$script_dir/Smoke.yaml"; then
       echo "✅ Smoke check passed — running widget flows."
       stop_recording discard
+      discard_debug_output
       return 0
     fi
     # Keep this attempt's clip — a launch crash / blank screen here is exactly what we want to see.
     stop_recording keep
     if [ "$attempt" -lt "$max_attempts" ]; then
       echo "⚠️  Smoke check attempt $attempt failed — resetting driver/simulator and retrying once."
-      # Reset the layer that actually flakes: on iOS restart the sim (re-runs prepare_ios.sh,
-      # re-establishing the Maestro driver); on Android just re-confirm the emulator is up.
-      if [ "$PLATFORM" == "android" ]; then
-        ensure_emulator_ready
-      else
-        restart_simulator
-      fi
+      reset_device
     fi
     attempt=$((attempt + 1))
   done
@@ -260,17 +448,14 @@ rerun_failed_tests() {
   for yaml_test_file in "${retry_failed_tests[@]}"; do
     retry_count=$((retry_count + 1))
     echo "🧪 Retrying test $retry_count/$total_retries: $(basename "$yaml_test_file")"
-    if [ "$PLATFORM" == "android" ]; then
-      ensure_emulator_ready
-    else
-      restart_simulator
-    fi
+    reset_device
     local attempt=0
     while [ $attempt -lt $MAX_RETRIES ]; do
       start_recording "$(basename "${yaml_test_file%.yaml}")"
-      if $HOME/.local/bin/maestro/bin/maestro test --env APP_ID=$APP_ID --env PLATFORM=$PLATFORM --env MAESTRO_DRIVER_STARTUP_TIMEOUT=$MAESTRO_DRIVER_STARTUP_TIMEOUT "$yaml_test_file"; then
+      if run_maestro "$yaml_test_file"; then
         echo "✅ Test passed: $yaml_test_file"
         stop_recording discard
+        discard_debug_output
         passed_tests+=("$yaml_test_file")
         break
       else

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

@@ -80,6 +80,10 @@ 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),
@@ -91,6 +95,7 @@ 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
@@ -355,6 +360,10 @@ 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;
             }
@@ -363,6 +372,17 @@ 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) {
+                return;
+            }
+
             // Only a user swipe reports a change here. Programmatic scrolls (initial positioning,
             // Next/Previous/pagination) already fired onSlideChange, so re-firing would double
             // count the change and, on remount, emit a spurious change back to slide 1.