Phase 4 checkpoint: chat-screen perf refactor + retryable blast-failure + repo-wide dispose-ref guardrail
Chat-screen performance (customer + mitra): - Parent screens have zero `ref.watch` — only `ref.listen` for side effects - Body extracted into its own `ConsumerStatefulWidget`; AppBar parts split into narrow `.select` consumers (mode, sensitivity, timer) - Per-second timer ticks routed to dedicated providers (`chatRemainingSecondsProvider` + new `mitraChatRemainingSecondsProvider`) so WS `session_tick` frames don't invalidate the rest of the chat state Dispose-in-ref bug fix: - `home_screen.dart`, `payment_screen.dart`, `mitra_chat_screen.dart` — ref-using cleanup moved from `dispose()` to `deactivate()`. Modern Riverpod invalidates `ref` the moment `dispose()` runs; the resulting silent error corrupts the widget-tree finalize and the next screen appears frozen - `halo_lints` package added at repo root with `no_ref_in_dispose` rule to catch this pattern in CI / IDE analysis - `custom_lint` activated in both apps' `analysis_options.yaml` (was installed but never wired in — also brings `riverpod_lint`'s `avoid_ref_inside_state_dispose` online) - CLAUDE.md Pitfalls section added to client_app + mitra_app Phase 4 §3 retryable blast-failure (Option A): - Backend `expirePairingRequest` + all-rejected use `recordIntermediateFailure` instead of `failPaymentSession` so the payment session stays `confirmed` for re-blast - WS `pairing_failed` payload carries `is_terminal: false` on the retryable paths; client parses the flag and exposes `retryBlast()` - "Coba cari lagi" CTA on S7 Timeout now re-blasts on the same payment - Pairing service test updated to reflect the new semantics Customer waiting-payment screen navigation patch: - `_navigateTerminal` uses `Future.microtask` + `addPostFrameCallback` redundancy after a release-mode bug where polling stopped but `context.go` never fired, leaving the screen visually stuck on "menunggu pembayaran" See requirement/resume-2026-05-15.md for next-day pickup checklist (mitra release rebuild + S21 Ultra install + retest is the gating item). Bundles unrelated in-flight Phase 4 §2.x work that was already on disk (ESP screen removal, USP one-time gate scaffolding, bestie-availability public route, OTP service edits, Maestro flow tweaks) — kept together to avoid a partial-rebase mess. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -3,15 +3,17 @@ import { countAvailableMitrasFromCache } from '../../services/mitra-status.servi
|
||||
import { UserType } from '../../constants.js'
|
||||
|
||||
/**
|
||||
* Customer-home availability poll.
|
||||
* Customer-authed availability poll (kept for CC/debug callers that want the
|
||||
* raw count).
|
||||
*
|
||||
* GET /api/client/mitra-availability → 200 { available: bool, count?: number }
|
||||
* GET /api/client/mitra-availability → 200 { available: bool, count: number }
|
||||
*
|
||||
* Hot endpoint by design — polled every 5s per active customer while their home is
|
||||
* foregrounded. Backed by a 10s in-memory cache (see mitra-status.service.js) so DB load
|
||||
* The customer home polls `/api/public/bestie/available` instead — that route
|
||||
* is unauthenticated and returns only the boolean, since SHome1st renders
|
||||
* before the user has any JWT (see `requirement/flow_customer.mermaid.md` §1).
|
||||
*
|
||||
* Backed by a 10s in-memory cache (see mitra-status.service.js) so DB load
|
||||
* stays bounded regardless of poller count. No rate limit by intent.
|
||||
*
|
||||
* `count` is included for CC/debug; the customer UI must read only `available`.
|
||||
*/
|
||||
export const clientMitraAvailabilityRoutes = async (app) => {
|
||||
app.get('/', { preHandler: [authenticate] }, async (request, reply) => {
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
import { countAvailableMitrasFromCache } from '../../services/mitra-status.service.js'
|
||||
|
||||
/**
|
||||
* Public bestie-availability beacon.
|
||||
*
|
||||
* GET /api/public/bestie/available → 200 { available: bool }
|
||||
*
|
||||
* Unauthenticated by design: the SHome1st CTA must reflect global availability
|
||||
* BEFORE the user has any JWT (see `requirement/flow_customer.mermaid.md` §1 +
|
||||
* router.dart's "fresh / unauthenticated users land on Home directly" carve-out).
|
||||
*
|
||||
* Output is intentionally a single boolean — no `count`, no IDs, no metadata —
|
||||
* so this endpoint leaks no operational signal beyond "at least one bestie is
|
||||
* online right now". Backed by the same 10s in-memory cache that bounds DB
|
||||
* load regardless of poller count.
|
||||
*
|
||||
* The auth'd `/api/client/mitra-availability` route is kept for CC/debug
|
||||
* callers that need the raw count.
|
||||
*/
|
||||
export const publicBestieAvailabilityRoutes = async (app) => {
|
||||
app.get('/available', async (_request, reply) => {
|
||||
const { available } = await countAvailableMitrasFromCache()
|
||||
return reply.send({ success: true, data: { available } })
|
||||
})
|
||||
}
|
||||
Reference in New Issue
Block a user