[defimomof2]

Summary

Resolved

• Keeper transactions have no time bounds (Preconditions::None), so a poll-timed-out transaction can still land minutes later #1236 — Keeper transactions have no time bounds (Preconditions::None), so a poll-timed-out transaction can still land minutes later

  Changes:

  • Added TX_MAX_TIME_SECS = 60 constant to tx_builder.rs — matches the poll budget (~6 attempts × up to 16 s backoff).
  • Added max_time: u64 parameter to build_invoke_tx; 0 means Preconditions::None (used for simulation calls where sequence is irrelevant).
  • Real submit callsites (set_prices, execute_handler) now pass now_unix + TX_MAX_TIME_SECS, so a timed-out transaction is guaranteed tx_too_late before the key is retried.
  • Simulation callsite passes 0 (no expiry needed).
  • Added TimeBounds, TimePoint to tx_builder.rs imports from stellar_xdr.
  • Extended existing unit test to assert Preconditions::None when max_time = 0; added new test for the Preconditions::Time path.

Closes #1236
closes #1247

To be completed

• Keeper integration tests mock RPC methods and response shapes that real Stellar RPC doesn't have, so CI validates the keeper against a fictional API #1247 — Keeper integration tests mock RPC methods and response shapes that real Stellar RPC does not return

[drips-wave]

@defimomof2 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits