ramadhan sjamsani
a09f37135c
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>
26 lines
1.1 KiB
JavaScript
26 lines
1.1 KiB
JavaScript
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 } })
|
|
})
|
|
}
|