FileSystemRequestQueueClient hardwires its state persistence to the default KVS via an internal StatePersistence struct. This makes it impossible to test the RQ client in isolation without a KVS directory on disk, or to swap in a different persistence backend. Extracting a trait StatePersistence { async fn load/save/clear } and providing the current KVS-backed implementation as the default would be low-cost and open the door to in-memory test doubles or alternative backends.
Note: the Python master implementation has the same constraint — RecoverableState accepts a persist_state_kvs_factory parameter, but the RQ client always passes a factory that opens the default filesystem KVS. No caller ever overrides it. So this is an existing design choice shared across both implementations, not a regression introduced by the Rust port.
FileSystemRequestQueueClienthardwires its state persistence to the default KVS via an internalStatePersistencestruct. This makes it impossible to test the RQ client in isolation without a KVS directory on disk, or to swap in a different persistence backend. Extracting atrait StatePersistence { async fn load/save/clear }and providing the current KVS-backed implementation as the default would be low-cost and open the door to in-memory test doubles or alternative backends.Note: the Python
masterimplementation has the same constraint —RecoverableStateaccepts apersist_state_kvs_factoryparameter, but the RQ client always passes a factory that opens the default filesystem KVS. No caller ever overrides it. So this is an existing design choice shared across both implementations, not a regression introduced by the Rust port.