-
Notifications
You must be signed in to change notification settings - Fork 1
feat(#270): drive waiting-state countdown from expiration_seconds + timeout_at #306
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,59 @@ | ||
| import 'package:mostro/src/rust/api/types.dart'; | ||
|
|
||
| /// The countdown target for a trade, resolved for #270. | ||
| /// | ||
| /// [deadlineEpochSeconds] is the unix-second instant the countdown runs to; | ||
| /// [totalWindowSeconds] sizes the progress ring (the full window). | ||
| typedef CountdownDeadline = ({int deadlineEpochSeconds, int totalWindowSeconds}); | ||
|
|
||
| /// Last-resort waiting-state window (seconds) when the node's instance event | ||
| /// omits `expiration_seconds`. Matches the Mostro daemon default (15 min). | ||
| const int kWaitingCountdownFallbackSeconds = 900; | ||
|
|
||
| /// Chooses the countdown target for a trade (#270): | ||
| /// | ||
| /// - **Pending**: counts to the 24 h pending-order expiry ([pendingExpiresAt]). | ||
| /// - **Waiting states** (buyer-invoice / payment): counts to the state-change | ||
| /// deadline — the trade's [timeoutAtEpoch] when the daemon persisted one, | ||
| /// else [waitingSinceEpoch] + `expiration_seconds` (the state-change message | ||
| /// timestamp plus the window, per the v1 timeout contract), falling back to | ||
| /// [kWaitingCountdownFallbackSeconds] for the window when the node omits it. | ||
| /// - **Any other state**: no countdown (null). | ||
| /// | ||
| /// The fallback is anchored on [waitingSinceEpoch] (a fixed timestamp such as | ||
| /// `TradeInfo.startedAt`) rather than the current time, so the deadline is | ||
| /// stable across the per-second rebuilds that drive the ticking UI — otherwise | ||
| /// a `now + window` deadline would slide forward every second and never reach | ||
| /// zero. This keeps the helper pure (no clock read, no cache). | ||
| /// | ||
| /// The UI only informs — the daemon stays the authority on expiry, so callers | ||
| /// never cancel locally at zero. | ||
| CountdownDeadline? waitingCountdownDeadline({ | ||
| required OrderStatus? status, | ||
| DateTime? pendingExpiresAt, | ||
| int? timeoutAtEpoch, | ||
| int? waitingSinceEpoch, | ||
| int? expirationSeconds, | ||
| }) { | ||
| final window = expirationSeconds ?? kWaitingCountdownFallbackSeconds; | ||
| switch (status) { | ||
| case OrderStatus.pending: | ||
| if (pendingExpiresAt == null) return null; | ||
| final deadline = pendingExpiresAt.millisecondsSinceEpoch ~/ 1000; | ||
| return (deadlineEpochSeconds: deadline, totalWindowSeconds: window); | ||
| case OrderStatus.waitingBuyerInvoice: | ||
| case OrderStatus.waitingPayment: | ||
| if (timeoutAtEpoch != null) { | ||
| return (deadlineEpochSeconds: timeoutAtEpoch, totalWindowSeconds: window); | ||
| } | ||
| if (waitingSinceEpoch != null) { | ||
| return ( | ||
| deadlineEpochSeconds: waitingSinceEpoch + window, | ||
| totalWindowSeconds: window, | ||
| ); | ||
| } | ||
| return null; | ||
| default: | ||
| return null; | ||
| } | ||
| } | ||
|
Comment on lines
+31
to
+59
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift Keep the fallback deadline stable. When Use a stable waiting-state start time, or use a shared cache keyed by order ID and waiting status. Do not derive As per coding guidelines, “Add targeted tests when expanding complex logic, asynchronous workflows, or protocol handling” and “run 🤖 Prompt for AI AgentsSource: Coding guidelines |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,118 @@ | ||
| import 'package:flutter_test/flutter_test.dart'; | ||
| import 'package:mostro/features/order/utils/waiting_countdown.dart'; | ||
| import 'package:mostro/src/rust/api/types.dart'; | ||
|
|
||
| void main() { | ||
| group('waitingCountdownDeadline', () { | ||
| test('pending counts to the pending expiry, window from expiration_seconds', | ||
| () { | ||
| final expiresAt = DateTime.fromMillisecondsSinceEpoch(2000 * 1000); | ||
| final r = waitingCountdownDeadline( | ||
| status: OrderStatus.pending, | ||
| pendingExpiresAt: expiresAt, | ||
| expirationSeconds: 900, | ||
| ); | ||
| expect(r, isNotNull); | ||
| expect(r!.deadlineEpochSeconds, 2000); | ||
| expect(r.totalWindowSeconds, 900); | ||
| }); | ||
|
|
||
| test('pending with no expiry yields no countdown', () { | ||
| final r = waitingCountdownDeadline( | ||
| status: OrderStatus.pending, | ||
| pendingExpiresAt: null, | ||
| expirationSeconds: 900, | ||
| ); | ||
| expect(r, isNull); | ||
| }); | ||
|
|
||
| test('waiting state prefers the persisted timeout_at', () { | ||
| for (final status in [ | ||
| OrderStatus.waitingBuyerInvoice, | ||
| OrderStatus.waitingPayment, | ||
| ]) { | ||
| final r = waitingCountdownDeadline( | ||
| status: status, | ||
| timeoutAtEpoch: 5000, | ||
| waitingSinceEpoch: 1000, | ||
| expirationSeconds: 900, | ||
| ); | ||
| expect(r, isNotNull, reason: '$status'); | ||
| expect(r!.deadlineEpochSeconds, 5000, reason: '$status'); | ||
| expect(r.totalWindowSeconds, 900, reason: '$status'); | ||
| } | ||
| }); | ||
|
|
||
| test('waiting falls back to startedAt + window when timeout_at is absent', | ||
| () { | ||
| final r = waitingCountdownDeadline( | ||
| status: OrderStatus.waitingPayment, | ||
| timeoutAtEpoch: null, | ||
| waitingSinceEpoch: 1000, | ||
| expirationSeconds: 900, | ||
| ); | ||
| expect(r, isNotNull); | ||
| expect(r!.deadlineEpochSeconds, 1900); // 1000 + 900, not now-based | ||
| expect(r.totalWindowSeconds, 900); | ||
| }); | ||
|
|
||
| test('waiting fallback uses the 900 s default when the node omits ' | ||
| 'expiration_seconds', () { | ||
| final r = waitingCountdownDeadline( | ||
| status: OrderStatus.waitingPayment, | ||
| timeoutAtEpoch: null, | ||
| waitingSinceEpoch: 1000, | ||
| expirationSeconds: null, | ||
| ); | ||
| expect(r, isNotNull); | ||
| expect(r!.totalWindowSeconds, kWaitingCountdownFallbackSeconds); | ||
| expect(r.deadlineEpochSeconds, 1000 + kWaitingCountdownFallbackSeconds); | ||
| }); | ||
|
|
||
| test('waiting with neither timeout_at nor a start anchor yields no ' | ||
| 'countdown', () { | ||
| final r = waitingCountdownDeadline( | ||
| status: OrderStatus.waitingBuyerInvoice, | ||
| timeoutAtEpoch: null, | ||
| waitingSinceEpoch: null, | ||
| expirationSeconds: 900, | ||
| ); | ||
| expect(r, isNull); | ||
| }); | ||
|
|
||
| test('non-countdown states produce no countdown', () { | ||
| for (final status in [ | ||
| OrderStatus.active, | ||
| OrderStatus.fiatSent, | ||
| OrderStatus.success, | ||
| OrderStatus.canceled, | ||
| null, | ||
| ]) { | ||
| final r = waitingCountdownDeadline( | ||
| status: status, | ||
| pendingExpiresAt: DateTime.fromMillisecondsSinceEpoch(2000 * 1000), | ||
| timeoutAtEpoch: 5000, | ||
| waitingSinceEpoch: 1000, | ||
| expirationSeconds: 900, | ||
| ); | ||
| expect(r, isNull, reason: '$status'); | ||
| } | ||
| }); | ||
|
|
||
| test('the fallback deadline is stable across repeated resolutions ' | ||
| '(#270 regression: no now-drift)', () { | ||
| CountdownDeadline? resolve() => waitingCountdownDeadline( | ||
| status: OrderStatus.waitingPayment, | ||
| timeoutAtEpoch: null, | ||
| waitingSinceEpoch: 1000, | ||
| expirationSeconds: 900, | ||
| ); | ||
| final first = resolve(); | ||
| final second = resolve(); | ||
| final third = resolve(); | ||
| expect(first!.deadlineEpochSeconds, 1900); | ||
| expect(second!.deadlineEpochSeconds, first.deadlineEpochSeconds); | ||
| expect(third!.deadlineEpochSeconds, first.deadlineEpochSeconds); | ||
| }); | ||
| }); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Use the snapshot status while live status resolves.
Line 94 uses
liveStatus ?? order.status. Line 102 passes onlyliveStatus. WhiletradeStatusProvideris loading, a known pending or waitingorder.statusproduces no countdown.Pass
liveStatus ?? order.statustowaitingCountdownDeadline. Add coverage for the provider-loading state.As per coding guidelines, “Add targeted tests when expanding complex logic, asynchronous workflows, or protocol handling.”
🤖 Prompt for AI Agents
Source: Coding guidelines