fix: use payment initiation timestamp for stale PENDING detection

[mostronator]

Summary

Fixes stale PENDING detection to use the actual payment initiation timestamp instead of the unrelated taken_at order field.

Closes #570

Problem

The stale PENDING cleanup query used taken_at (when the order was taken by a counterparty) to determine if a PENDING dev fee entry is stale. This is wrong because:

• False positive: An order taken 2 weeks ago with a fresh payment attempt would be immediately flagged as stale → payment reset → potential duplicate
• False negative: An order taken 5 minutes ago with a genuinely stuck payment would never be flagged → stuck forever

Solution (Option A from the issue — no schema change)

PENDING marker now includes timestamp

Before: PENDING-{order_id}
After:  PENDING-{order_id}-{unix_timestamp}

Stale detection parses timestamp from marker

Instead of a SQL WHERE taken_at < cutoff, we now:

1. Fetch all PENDING-% rows
2. Parse the unix timestamp from each marker via parse_pending_timestamp()
3. Compare against the 5-minute TTL
4. Legacy markers (without timestamp) are treated as stale for backward compatibility

Timestamp parsing

Since order IDs are UUIDs (containing dashes), the parser uses rsplit to get the last segment and validates it's exactly 10 decimal digits (valid for unix timestamps 2001–2286), distinguishing it from UUID hex segments.

Tests

5 new unit tests for parse_pending_timestamp():

• New format with UUID order ID ✅
• Legacy UUID format (no timestamp) ✅
• Legacy simple format ✅
• Non-PENDING string ✅
• Empty string ✅

Verification

• ✅ cargo fmt — clean
• ✅ cargo clippy --all-targets --all-features — clean
• ✅ cargo test — 117 passed, 0 failed

[coderabbitai]

Warning

Rate limit exceeded

@mostronator has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 14 minutes and 12 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/stale-pending-timestamp

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}