User Story
As a liquidity provider, I want my payment orders to succeed even if the priority queue refreshes between rate fetch and order initiation, so that my orders do not fail due to rate mismatches.

Acceptance Criteria

1. GIVEN a payment order is being assigned to a provider
   WHEN the priority queue refreshes between rate fetch and order initiation
   THEN the system should check both the current and previous rates for a match before proceeding with the order.

2. GIVEN a provider's rate is fetched and stored in Redis
   WHEN the priority queue refreshes
   THEN the previous rate should be saved in a separate Redis key (e.g., bucket_NGN_1_500000_prev) for reference during order assignment.

3. GIVEN a payment order is being assigned
   WHEN the current rate does not match the order's rate
   THEN the system should check the previous rate stored in Redis and proceed if it matches.

Tech Details

1. Modify the CreatePriorityQueueForBucket function to save the previous queue to a Redis key with the suffix _prev (e.g., bucket_NGN_1_500000_prev) before updating the current queue.
2. Update the AssignLockPaymentOrder function to check both the current and previous queues for a rate match before assigning the order.
3. Ensure the Redis keys for previous rates are cleaned up or updated appropriately during queue refreshes.

Notes/Assumptions

1. The previous rate queue (_prev) will only be used as a fallback when the current rate does not match the order's rate.
2. The previous rate queue will be overwritten every time the priority queue refreshes.
3. This solution assumes that the rate discrepancy is due to timing issues between queue refreshes and order assignments.

Open Questions