Validation test timing sensitivity in test_worker_lock_renewal_extends_timeout

[affandar]

Problem

The test_worker_lock_renewal_extends_timeout validation test in src/provider_validation/lock_expiration.rs uses tight timing windows (800ms sleeps with 1s lock timeouts) that don't account for network latency when running against remote databases.

Test Timeline Analysis

The test does:

1. T=0: Fetch work item with 1s lock timeout → locked_until = T+1000ms
2. T=800ms: Sleep completes, renew lock for 1s → locked_until = max(1000, 800) + 1000 = 2000ms
3. T=1600ms: Sleep completes, fetch should fail (lock expires at 2000ms)

Issue with Remote Databases

With remote database latency (~40-60ms per query), the timing drifts:

• Fetch takes ~40ms
• Renewal takes ~40ms (at T=840ms instead of T=800ms)
• Final fetch takes ~60ms
• Cumulative latency: ~150-200ms

This means the final fetch can complete around T=1700-1800ms, dangerously close to the 2000ms expiration. With any additional processing overhead, the lock expires before the check.

Logs from Failure

duration_ms=64.04670899999999
attempt_count=2  // Item was re-fetched because lock expired!
thread 'test_worker_lock_renewal_extends_timeout' panicked:
Item should still be locked after renewal

Proposed Fix

Use larger timing margins to accommodate network latency:

// Current (too tight)
let short_timeout = Duration::from_secs(1);
tokio::time::sleep(Duration::from_millis(800)).await;  // 80% of timeout
// ... renew ...
tokio::time::sleep(Duration::from_millis(800)).await;  // total 1.6s, expires at 2s

// Proposed (more margin)
let short_timeout = Duration::from_secs(2);
tokio::time::sleep(Duration::from_millis(1500)).await;  // 75% of timeout
// ... renew ...
tokio::time::sleep(Duration::from_millis(1500)).await;  // total 3s, expires at 4s (1s margin)

Or accept a ProviderFactory::network_latency_budget() hint to adjust timing dynamically.

Environment

• duroxide version: 0.1.6
• Database: Azure PostgreSQL (West US region)
• Network latency: ~40-60ms per query