rama/halobestie-clone
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Phase 4 checkpoint: chat-screen perf refactor + retryable blast-failure + repo-wide dispose-ref guardrail

Browse Source 
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:
ramadhan sjamsani
2026-05-14 19:12:34 +08:00
parent a48f108fc0
commit a09f37135c
56 changed files with 3417 additions and 1093 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
client_app/lib/core/api/api_client.dart
View File

@@ -54,8 +54,16 @@ class ApiClient {
));
}
Future<Map<String, dynamic>> get(String path, {Map<String, dynamic>? queryParameters}) async {
final response = await _dio.get(path, queryParameters: queryParameters);
Future<Map<String, dynamic>> get(
String path, {
Map<String, dynamic>? queryParameters,
bool skipAuth = false,
}) async {
final response = await _dio.get(
path,
queryParameters: queryParameters,
options: skipAuth ? Options(extra: {_skipAuthKey: true}) : null,
);
return response.data as Map<String, dynamic>;
}

17
client_app/lib/core/availability/mitra_availability_notifier.dart
View File

@@ -6,16 +6,16 @@ part 'mitra_availability_notifier.g.dart';
/// Customer-home availability poll.
///
/// Polls `GET /api/client/mitra-availability` every 5 seconds while the home
/// screen is in the foreground. Polling is gated by the home screen calling
/// [setActive] from `WidgetsBindingObserver.didChangeAppLifecycleState`:
/// Polls `GET /api/public/bestie/available` every 5 seconds while the home
/// screen is in the foreground. The endpoint is unauthenticated by design —
/// SHome1st renders before any JWT exists, and the CTA's enabled state needs
/// to reflect global availability so users see whether bestie is online
/// before committing to onboarding. Polling is gated by the home screen
/// calling [setActive] from `WidgetsBindingObserver.didChangeAppLifecycleState`:
/// - resumed → setActive(true)
/// - paused/inactive → setActive(false)
///
/// On any HTTP error we emit `false` (never display stale state).
///
/// The endpoint also returns a `count`, but the customer UI must only read the
/// binary `available` field — the count is for CC/debug only.
@Riverpod(keepAlive: true)
class MitraAvailability extends _$MitraAvailability {
Timer? _pollTimer;
@@ -63,7 +63,10 @@ class MitraAvailability extends _$MitraAvailability {
bool available;
try {
final api = ref.read(apiClientProvider);
final response = await api.get('/api/client/mitra-availability');
final response = await api.get(
'/api/public/bestie/available',
skipAuth: true,
);
final data = response['data'] as Map<String, dynamic>?;
available = data?['available'] as bool? ?? false;
} catch (_) {

14
client_app/lib/core/availability/mitra_availability_notifier.g.dart
View File

@@ -6,21 +6,21 @@ part of 'mitra_availability_notifier.dart';
// RiverpodGenerator
// **************************************************************************
String _$mitraAvailabilityHash() => r'036de8fea66c6a0114abd4a422af12186c1447d7';
String _$mitraAvailabilityHash() => r'e385c671720973cd1cea4b15933cd59421f035f0';
/// Customer-home availability poll.
///
/// Polls `GET /api/client/mitra-availability` every 5 seconds while the home
/// screen is in the foreground. Polling is gated by the home screen calling
/// [setActive] from `WidgetsBindingObserver.didChangeAppLifecycleState`:
/// Polls `GET /api/public/bestie/available` every 5 seconds while the home
/// screen is in the foreground. The endpoint is unauthenticated by design —
/// SHome1st renders before any JWT exists, and the CTA's enabled state needs
/// to reflect global availability so users see whether bestie is online
/// before committing to onboarding. Polling is gated by the home screen
/// calling [setActive] from `WidgetsBindingObserver.didChangeAppLifecycleState`:
/// - resumed → setActive(true)
/// - paused/inactive → setActive(false)
///
/// On any HTTP error we emit `false` (never display stale state).
///
/// The endpoint also returns a `count`, but the customer UI must only read the
/// binary `available` field — the count is for CC/debug only.
///
/// Copied from [MitraAvailability].
@ProviderFor(MitraAvailability)
final mitraAvailabilityProvider =

8
client_app/lib/core/chat/chat_notifier.dart
View File

@@ -456,10 +456,18 @@ class Chat extends _$Chat {
case WsMessage.extensionResponse:
final accepted = data['accepted'] as bool? ?? false;
// On accept, the backend includes the freshly-extended `expires_at` so
// the local ticker can resume immediately (otherwise it would be stuck
// at 0 / the just-expired moment until the next SESSION_TIMER ping).
final extendedExpiresAtRaw = data['expires_at'] as String?;
final extendedExpiresAt = (accepted && extendedExpiresAtRaw != null)
? DateTime.tryParse(extendedExpiresAtRaw)?.toLocal()
: null;
state = current.copyWith(
extensionResponse: data,
sessionPaused: accepted ? false : current.sessionPaused,
sessionExpired: accepted ? false : current.sessionExpired,
expiresAt: extendedExpiresAt ?? current.expiresAt,
);
break;

2
client_app/lib/core/chat/chat_notifier.g.dart
View File

@@ -30,7 +30,7 @@ final chatRemainingSecondsProvider = AutoDisposeStreamProvider<int>.internal(
@Deprecated('Will be removed in 3.0. Use Ref instead')
// ignore: unused_element
typedef ChatRemainingSecondsRef = AutoDisposeStreamProviderRef<int>;
String _$chatHash() => r'f9d77e176acb682dc6477635e0e80a09e846988b';
String _$chatHash() => r'a42bf404f5b38034c6c9511259b64b1092af3caa';
/// See also [Chat].
@ProviderFor(Chat)

2
client_app/lib/core/chat/session_closure_notifier.g.dart
View File

@@ -6,7 +6,7 @@ part of 'session_closure_notifier.dart';
// RiverpodGenerator
// **************************************************************************
String _$sessionClosureHash() => r'521e57f74805faf01f11778872cb37ceae683a5b';
String _$sessionClosureHash() => r'a9aaf26da64d3489497d057e2b05741c08444e07';
/// See also [SessionClosure].
@ProviderFor(SessionClosure)

54
client_app/lib/core/pairing/pairing_notifier.dart
View File

@@ -30,9 +30,14 @@ class PairingSearchingData extends PairingData {
/// the payment-session-scoped cancel endpoint without re-prompting.
final String paymentSessionId;
/// Carried so a retryable PAIRING_FAILED can preserve the customer's original
/// topic choice when looping back into Blast via retryBlast().
final TopicSensitivity topicSensitivity;
const PairingSearchingData({
required this.sessionId,
required this.paymentSessionId,
required this.topicSensitivity,
});
}
@@ -105,13 +110,26 @@ class PairingTargetedUnavailableData extends PairingData {
});
}
/// Terminal pairing failure — payment session is in `failed_pairing`. Routes
/// to the failed-pairing screen (no_bestie_screen).
/// Pairing failure surfaced on the S7 Timeout screen.
///
/// `isRetryable=true` means the backend kept the payment session `confirmed`
/// (audit-only failure) so the customer can re-blast on the same payment via
/// `retryBlast()`. `isRetryable=false` means the payment is in `failed_pairing`
/// and any retry must start from a fresh payment session.
class PairingFailedData extends PairingData {
final PairingFailureCause cause;
final String? paymentSessionId;
final bool isRetryable;
// Carried so retryBlast() can re-issue the blast with the customer's original
// topic choice. Null when the failure originated before any topic was known.
final TopicSensitivity? topicSensitivity;
const PairingFailedData({required this.cause, this.paymentSessionId});
const PairingFailedData({
required this.cause,
this.paymentSessionId,
this.isRetryable = false,
this.topicSensitivity,
});
}
class PairingCancelledData extends PairingData {
@@ -156,6 +174,7 @@ class Pairing extends _$Pairing {
state = PairingSearchingData(
sessionId: sessionId,
paymentSessionId: paymentSessionId,
topicSensitivity: topicSensitivity,
);
} on DioException catch (e) {
_cleanup();
@@ -279,6 +298,7 @@ class Pairing extends _$Pairing {
state = PairingSearchingData(
sessionId: sessionId,
paymentSessionId: paymentSessionId,
topicSensitivity: topicSensitivity,
);
} on DioException catch (e) {
_cleanup();
@@ -302,6 +322,25 @@ class Pairing extends _$Pairing {
state = const PairingInitialData();
}
/// "Coba Cari Lagi" CTA on the S7 Timeout screen when the payment was kept
/// `confirmed` (retryable failure). Re-blasts on the same payment session.
///
/// Caller should only invoke this when `state is PairingFailedData &&
/// state.isRetryable && paymentSessionId != null && topicSensitivity != null`.
Future<void> retryBlast() async {
final current = state;
if (current is! PairingFailedData
|| !current.isRetryable
|| current.paymentSessionId == null
|| current.topicSensitivity == null) {
return;
}
await startSearch(
paymentSessionId: current.paymentSessionId!,
topicSensitivity: current.topicSensitivity!,
);
}
// ---- Internal ---------------------------------------------------------
Future<void> _connectWebSocket() async {
@@ -348,13 +387,20 @@ class Pairing extends _$Pairing {
}
if (type == WsMessage.pairingFailed) {
// Terminal — payment_session is in failed_pairing server-side.
final causeTag = data['cause_tag'] as String?;
final paymentSessionId = data['payment_session_id'] as String?;
// Missing flag = terminal (backward-compat with older emit sites). When
// false, the backend kept the payment confirmed and we can re-blast.
final isRetryable = data['is_terminal'] == false;
final carriedTopic = current is PairingSearchingData
? current.topicSensitivity
: null;
_cleanup();
state = PairingFailedData(
cause: PairingFailureCause.fromString(causeTag),
paymentSessionId: paymentSessionId,
isRetryable: isRetryable,
topicSensitivity: carriedTopic,
);
return;
}