Echo Hardest AMRAP: VBT verbal encouragement cut off, set ends prematurely on 3rd of 3

[9thLevelSoftware]

Summary

While running Echo mode on Hardest with VBT (Velocity-Based Training) enabled and AMRAP set, a verbal encouragement triggered by VBT was cut off mid-playback and the set was ended early, with the set completion audio cue playing right after. "Auto-End on Velocity loss" was OFF, so the only velocity-related trigger should have been the verbal encouragement itself.

Reporter

• Discord: stugotz0955_50891
• Message ID: 1525205378139164823
• Thread: 1525205378139164823 (#bug-reports)

Type

Bug

Repo

• mobile (9thlevelsoftware/project-phoenix-mp)

Version / Platform / Device

• App version: v0.9.5
• OS: Android 16
• Device: Pixel 10 Pro XL

Workout Configuration

• Exercise: calf-raise Echo
• Mode: Echo (Hardest)
• Set: 3rd of 3, set to AMRAP
• VBT: enabled (verbal encouragement triggered by VBT)
• Auto-End on Velocity loss: NOT enabled (only verbal encouragement)

Steps to Reproduce

1. Open Project Phoenix and pair the Vitruvian trainer.
2. Select an Echo exercise (reporter used Calf-Raise Echo).
3. Configure Echo mode on Hardest.
4. Set up a set that uses AMRAP, with VBT / verbal encouragement enabled.
5. Run the workout into the 3rd set of 3.
6. Wait for VBT to trigger the verbal encouragement audio cue.
7. Observe whether the set ends prematurely while encouragement is still playing.

Expected Behavior

• The verbal encouragement should play fully to completion.
• The set should only end when the normal set-end criteria are met (reps complete / AMRAP user stop / rest), not solely because the VBT-trigered encouragement was issued.
• The set completion audio cue should not overlap or cut off the encouragement.

Actual Behavior

• VBT triggered a verbal encouragement.
• The encouragement was cut off before it finished playing.
• The set ended prematurely (only 3 reps on a 3rd-of-3 AMRAP set).
• The set completion audio cue played immediately after the (cut-off) encouragement.

Impact / Notes

• Significantly affects AMRAP / Hardest-mode Echo sets: users cannot use the full encouragement audio and the final set is silently capped at VBT trigger rather than reps-complete / user-finish.
• Reporter context: maintainer hypothesis in the same channel (stall detection and vbt may be conflicting, and stall detection may be obsolete given the VBT implementation). This is a debugging hypothesis only, not reporter testimony, and is preserved here for engineering reference.

Attachments

• None recorded.

Original Discord Report

v0.9.5
Android 16
Pixel 10 Pro XL

I had my 3rd set of 3 end prematurely after 3 reps, set to AMRAP when VBT was triggered and I got a verbal encouragement.  The encouragement was cut off before it finished playing to the set ending and the set completion audio cue played.  I do not have "Auto-End on Velocity loss enabled"  just the verbal encouragement.  The particular set was calf-raise Echo  on Hardest mode.

Maintainer context from the same #bug-reports channel before intake (Discord message 1525248001101009066; treat as a debugging hypothesis, not reporter testimony):
Hmm...wonder if stall detection and vbt are conflicting with each other.  Suspect stall detection might actually be obsolete with the vbt implementation.

[9thLevelSoftware]

RCA: AMRAP auto-stop is independent of the disabled VBT auto-end setting

Evidence used

• Original report: Android 16 / Pixel 10 Pro XL / Echo Hardest AMRAP, VBT verbal encouragement enabled, Auto-End on Velocity Loss disabled.
• Recreation packet: REPRODUCED at code-path level on main@6059f8ee0aabfbda0473af0ec36344f5bda69f8b; physical trainer/device replay was unavailable.
• No reporter clarification was needed. The report plus source trace determine the affected path.

Root cause

The disabled setting is being honored by the VBT auto-end branch, but it does not govern the separate AMRAP auto-stop paths:

1. ActiveSessionEngine.checkVelocityThreshold() emits the one-shot VBT threshold and verbal-encouragement events. Its call to handleSetCompletion() is correctly gated by both two consecutive threshold reps and coordinator.autoEndOnVelocityLoss (ActiveSessionEngine.kt:1304-1339). With the reporter's setting off, this branch does not end the set.
2. Independently, after warm-up, AMRAP unconditionally enables the position-based auto-stop path: shouldRunPositionBasedAutoStop() returns true for params.isAMRAP, and shouldEnableAutoStop() does not consult autoEndOnVelocityLoss (ActiveSessionEngine.kt:980-994). A 2.5-second handles-at-rest interval then calls requestAutoStop() -> triggerAutoStop() -> handleSetCompletion() (ActiveSessionEngine.kt:1452-1484, 1015-1039). This path is sufficient to reproduce the premature completion even if stall detection is disabled.
3. If exercise stall detection is enabled, a second independent velocity-stall path can also finish the set after five seconds (ActiveSessionEngine.kt:1411-1450). The report does not establish that this alternate path fired, so it is an additional risk, not the primary attribution.
4. The VBT one-shot state only prevents duplicate cue emission. It does not defer either auto-stop timer. Once automatic completion runs, handleSetCompletion() stops the BLE workout and emits WORKOUT_END (ActiveSessionEngine.kt:3795-3867, 3882). The end cue arriving during the verbal cue explains the observed cut-off/overlap; there is no separate audio root cause required to reproduce this ticket.

The settings route is intact: Settings UI -> MainViewModel -> SettingsManager -> PreferencesManager -> DefaultWorkoutSessionManager.updateVbtSettings() -> WorkoutCoordinator.autoEndOnVelocityLoss (NavGraph.kt:413-418, MainViewModel.kt:354-355, DefaultWorkoutSessionManager.kt:308-315). This is a coordination bug between the independent auto-stop policy and the verbal VBT cue, not a failed preference persistence bug.

Binding fix direction

Implement the smallest shared-session guard in WorkoutCoordinator / ActiveSessionEngine:

• When checkVelocityThreshold() emits VERBAL_ENCOURAGEMENT while autoEndOnVelocityLoss is false, mark the current set as auto-stop-deferred-until-next-completed-working-rep.
• While that marker is set, checkAutoStop() must reset both position and velocity-stall countdown state and return before either can call requestAutoStop().
• Clear the marker only after a later completed working rep, and reset it with the existing per-set reset path. Do not clear it merely because another low-velocity metric arrives.

Using the next completed rep as the boundary avoids inventing a guessed speech-duration timeout: the reporter's pause immediately after the encouragement cannot terminate the set, and normal AMRAP auto-stop resumes only after the user has explicitly continued.

Regression target and acceptance criteria

Extend the existing DWSMWorkoutLifecycleTest / DWSMTestHarness auto-stop coverage:

1. With isAMRAP=true, warm-up complete, autoEndOnVelocityLoss=false, and a verbal-VBT event emitted, stationary metrics beyond both 2.5 and 5 seconds must leave the workout Active, make no BLE stop call, and emit no WORKOUT_END.
2. After the next completed working rep, the same valid AMRAP resting condition must again complete normally. This proves the guard is a defer, not a permanent disable.
3. Preserve VbtAutoEndTest behavior: two consecutive threshold reps with autoEndOnVelocityLoss=true still auto-end; disabled VBT auto-end alone still does not auto-end.
4. Cover stallDetectionEnabled=false in the first case to prove the unconditional AMRAP position path is protected, then cover the enabled path so neither timer bypasses the guard.

Non-goals

• Do not remove or globally disable stall detection.
• Do not change explicit user stop, BLE safety/emergency-stop behavior, fixed-rep completion, or the existing enabled VBT auto-end behavior.
• Do not redesign the Android audio stack in this fix. Preventing the erroneous WORKOUT_END emission removes the reported competing end cue at its source.