feat(#270): drive waiting-state countdown from expiration_seconds + timeout_at #306
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,64 @@ | ||
| 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 trade's | ||
| /// [timeoutAtEpoch] when one is present, else **no countdown** (null). | ||
| /// There is deliberately no `startedAt`-based fallback: `startedAt` is the | ||
| /// order-creation time, so for a maker whose order sat in the book before | ||
| /// being taken it yields a deadline already in the past — a countdown born at | ||
| /// zero. "No anchor, no countdown" is correct until the daemon stamps | ||
| /// `timeout_at` on waiting-state entry from the node's `expiration_seconds` | ||
| /// (a follow-up daemon change; #306 review). Today `timeout_at` is a fixed | ||
| /// 900 written client-side on take, not persisted by the daemon. | ||
| /// - **Any other state**: no countdown (null). | ||
| /// | ||
| /// The helper is pure — no clock read, no cache — so its result is stable across | ||
| /// the per-second rebuilds that drive the ticking UI. | ||
| /// | ||
| /// 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? pendingCreatedAtEpoch, | ||
| int? timeoutAtEpoch, | ||
| int? expirationSeconds, | ||
| }) { | ||
| final window = expirationSeconds ?? kWaitingCountdownFallbackSeconds; | ||
| switch (status) { | ||
| case OrderStatus.pending: | ||
| if (pendingExpiresAt == null) return null; | ||
| final deadline = pendingExpiresAt.millisecondsSinceEpoch ~/ 1000; | ||
| // The ring spans the whole pending window (creation -> 24 h expiry), not | ||
| // the waiting window, so the progress ring is meaningful (#306 review). | ||
| final total = | ||
| (pendingCreatedAtEpoch != null && deadline > pendingCreatedAtEpoch) | ||
| ? deadline - pendingCreatedAtEpoch | ||
| : window; | ||
| return (deadlineEpochSeconds: deadline, totalWindowSeconds: total); | ||
| case OrderStatus.waitingBuyerInvoice: | ||
| case OrderStatus.waitingPayment: | ||
| // Only count down when timeout_at is present. The startedAt fallback | ||
| // produced a past deadline for makers (startedAt is creation time), so | ||
| // "no anchor, no countdown" until the daemon stamps timeout_at properly | ||
| // (#306 review). | ||
| if (timeoutAtEpoch != null) { | ||
| return (deadlineEpochSeconds: timeoutAtEpoch, totalWindowSeconds: window); | ||
| } | ||
| return null; | ||
| default: | ||
| return null; | ||
| } | ||
| } | ||
|
Comment on lines
+32
to
+64
Contributor
There was a problem hiding this comment. 🎯 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 |
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,117 @@ | ||
| 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; ring spans creation to expiry', | ||
| () { | ||
| // 24 h window: created at epoch 1000, expires at 1000 + 86400. | ||
| const createdAt = 1000; | ||
| final expiresAt = | ||
| DateTime.fromMillisecondsSinceEpoch((createdAt + 86400) * 1000); | ||
| final r = waitingCountdownDeadline( | ||
| status: OrderStatus.pending, | ||
| pendingExpiresAt: expiresAt, | ||
| pendingCreatedAtEpoch: createdAt, | ||
| expirationSeconds: 900, | ||
| ); | ||
| expect(r, isNotNull); | ||
| expect(r!.deadlineEpochSeconds, createdAt + 86400); | ||
| // The ring spans the whole pending window, not the waiting window (#306). | ||
| expect(r.totalWindowSeconds, 86400); | ||
| }); | ||
|
|
||
| test('pending ring falls back to the window when no createdAt is given', () { | ||
| final r = waitingCountdownDeadline( | ||
| status: OrderStatus.pending, | ||
| pendingExpiresAt: DateTime.fromMillisecondsSinceEpoch(2000 * 1000), | ||
| pendingCreatedAtEpoch: null, | ||
| 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 counts to the persisted timeout_at', () { | ||
| for (final status in [ | ||
| OrderStatus.waitingBuyerInvoice, | ||
| OrderStatus.waitingPayment, | ||
| ]) { | ||
| final r = waitingCountdownDeadline( | ||
| status: status, | ||
| timeoutAtEpoch: 5000, | ||
| expirationSeconds: 900, | ||
| ); | ||
| expect(r, isNotNull, reason: '$status'); | ||
| expect(r!.deadlineEpochSeconds, 5000, reason: '$status'); | ||
| expect(r.totalWindowSeconds, 900, reason: '$status'); | ||
| } | ||
| }); | ||
|
|
||
| test( | ||
| 'a waiting order with no timeout_at yields no countdown, not a past ' | ||
| 'deadline (#306: no startedAt fallback)', () { | ||
| // startedAt is order-creation time; for a maker whose order sat in the | ||
| // book before being taken, anchoring on it produced a deadline already in | ||
| // the past — a countdown born at zero. With no timeout_at the helper now | ||
| // returns null rather than a bogus deadline. | ||
| for (final status in [ | ||
| OrderStatus.waitingBuyerInvoice, | ||
| OrderStatus.waitingPayment, | ||
| ]) { | ||
| final r = waitingCountdownDeadline( | ||
| status: status, | ||
| timeoutAtEpoch: null, | ||
| expirationSeconds: 900, | ||
| ); | ||
| expect(r, isNull, reason: '$status'); | ||
| } | ||
| }); | ||
|
|
||
| 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, | ||
| expirationSeconds: 900, | ||
| ); | ||
| expect(r, isNull, reason: '$status'); | ||
| } | ||
| }); | ||
|
|
||
| test('the resolved deadline is stable across repeated resolutions ' | ||
| '(#270 regression: no now-drift)', () { | ||
| // The helper is pure: given the same inputs it returns the same deadline, | ||
| // so the ticking per-second rebuild never slides the target forward. | ||
| CountdownDeadline? resolve() => waitingCountdownDeadline( | ||
| status: OrderStatus.waitingPayment, | ||
| timeoutAtEpoch: 5000, | ||
| expirationSeconds: 900, | ||
| ); | ||
| final first = resolve(); | ||
| final second = resolve(); | ||
| final third = resolve(); | ||
| expect(first!.deadlineEpochSeconds, 5000); | ||
| expect(second!.deadlineEpochSeconds, first.deadlineEpochSeconds); | ||
| expect(third!.deadlineEpochSeconds, first.deadlineEpochSeconds); | ||
| }); | ||
| }); | ||
| } |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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