Ramadhan Sjamsani
368d18a0bf
Verified the 2026-05-15 disconnect() fix end-to-end on emulator-5556: mitra logs in → online → accepts blast → backend force-expires → goodbye composer renders → back-press → lands on Bestie Home with online status preserved, zero flutter:E in logcat. - ts-mitra-3-08-back_press_after_session_expired_no_red_screen.yaml codifies the repro for Maestro. Extends ts-mitra-3-04 with the back-tap + home-assertion + red-screen guard. - mitra_app/CLAUDE.md adds a Pitfall section beneath the existing "no ref in dispose" rule: never mutate notifier state synchronously from deactivate() cleanup — wrap in SchedulerBinding.addPostFrameCallback or Riverpod throws "Tried to modify a provider while the widget tree was building" during the back-nav teardown. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mitra_app Maestro flows
End-to-end UI automation for the mitra Flutter app using Maestro. Single-emulator + curl-as-customer pattern — when a flow needs a customer to "do something", it's simulated via backend API calls fired from runScript steps.
One-time install
See client_app/.maestro/README.md — Maestro is a global CLI, install once and it serves both apps.
You also need:
adbon your PATH (Android Studio platform-tools)jq(apt install jq/brew install jq)- One Android emulator OR one connected device — only one at a time (per project decision)
Folder layout
.maestro/
├── README.md # this file
├── config.yaml # shared env: app IDs, backend URL, test credentials
├── flows/
│ ├── 01_smoke.yaml
│ ├── 02_online_offline_toggle.yaml
│ └── 03_accept_general_blast.yaml
└── scripts/
└── customer_blast_now.sh
Configure for your environment
Edit .maestro/config.yaml and fill in:
BACKEND_URL— must match the--dart-define=API_BASE_URL=...value the installed APK was built withTEST_CUSTOMER_IDandTEST_CUSTOMER_JWT— used by the curl harness to fire blasts toward this mitra
Run a flow
maestro test mitra_app/.maestro/flows/01_smoke.yaml
# all flows
maestro test mitra_app/.maestro/flows/
If multiple devices are attached:
adb devices
maestro --device emulator-5554 test mitra_app/.maestro/flows/01_smoke.yaml
Per-machine overrides
Override config.yaml values at runtime:
maestro test \
--env BACKEND_URL=http://192.168.99.10:3000 \
--env TEST_CUSTOMER_JWT=eyJhbGc... \
mitra_app/.maestro/flows/03_accept_general_blast.yaml
Single-emulator + curl pattern
This mirrors the client_app pattern. When a mitra-side flow needs the customer to act, the flow uses runScript: to fire the customer's API calls directly:
- Mitra app is on screen via Maestro on the only connected device
runScript: ../scripts/customer_blast_now.shcreates + confirms a payment_session and fires a chat request as a "fake" customer- The mitra app receives the blast via WS as it would from a real customer; Maestro asserts the overlay appears
For the customer-side equivalent (drive customer with Maestro, simulate mitra via curl), see client_app/.maestro/.
When to run mitra flows vs. client_app flows
- Default: drive the customer side via
client_app/.maestro/. Most Phase 3.7 assertions live there (CTA gating, payment screen, searching screen, failed-pairing terminal, "Curhat lagi" overlays). - Run mitra flows when you specifically need to assert mitra UI:
- Returning-chat 20s countdown actually visible + ticking
- Extension card copy reads "otomatis disetujui"
- Online/offline toggle behavior (Section J — mitra goes offline mid-session)
- Incoming-request overlay accept/decline buttons
Adding a new flow
See client_app/.maestro/README.md — same pattern.
Troubleshooting
See client_app/.maestro/README.md — same checklist applies.