**Motivations:**
- Anchor API requests were being aborted with 'This operation was aborted' error
- API anchorage had performance issues causing long response times (30-60s)
- Mutex could block indefinitely if a previous request crashed or timed out
**Root causes:**
- No timeout on mutex acquisition, causing indefinite blocking
- Sequential RPC calls (8+ getNewAddress calls) instead of parallel
- Expensive fee calculation making N RPC calls (one per input) instead of using known UTXO amounts
- RPC timeout too short (30s) for slow Bitcoin node operations
- No guarantee of mutex release in error cases
**Correctifs:**
- Added 180s timeout on mutex acquisition with Promise.race() to prevent indefinite blocking
- Parallelized getNewAddress() calls with Promise.all() (9 sequential calls → 1 parallel call)
- Optimized fee calculation to use known UTXO amounts instead of getRawTransaction() per input (saves N RPC calls, up to 20+)
- Increased RPC timeout from 30s to 120s in .env.example
- Added finally block to guarantee mutex release in all cases (success, error, timeout)
- Added timeout and explicit error handling in api-filigrane callAnchorAPI() with AbortController (120s timeout)
**Evolutions:**
- Performance improvement: execution time reduced from ~30-60s to ~10-20s
- RPC calls reduction: from ~15-35 calls to ~8-12 calls per anchor transaction
- Better resilience: mutex cannot block indefinitely anymore
- Improved error messages with explicit timeout/abort information
**Pages affectées:**
- api-anchorage/src/bitcoin-rpc.js: mutex timeout, parallel address generation, optimized fee calculation, finally block
- api-anchorage/.env.example: increased RPC timeout to 120s
- api-filigrane/src/routes/watermark.js: timeout and error handling for anchor API calls
- fixKnowledge/api-filigrane-anchor-request-aborted.md: documentation of issues and fixes
**Motivations:**
- Anchor API requests were timing out with "This operation was aborted" errors
- Multiple simultaneous anchor requests can wait for mutex, causing delays
- Slow Bitcoin RPC calls can exceed the 120s timeout
**Root causes:**
- Timeout of 120s was too short when multiple anchors are in progress (mutex wait)
- Slow Bitcoin RPC operations (listunspent, createrawtransaction, sign, send) can take longer than 120s
- Insufficient logging made it difficult to diagnose timeout vs connection closure
**Correctifs:**
- Increased ANCHOR_API_TIMEOUT_MS from 120000 (120s) to 180000 (180s) to handle mutex waits and slow RPC calls
- Added start time tracking to measure elapsed time for all operations
- Enhanced logging with:
- Log at request start with url, documentUid, hash (truncated), timeoutMs
- Log on success with txid and elapsedMs
- Log on abort with elapsedMs, timeoutMs, errorName, errorCode
- Log on failure with elapsedMs, errorName, errorCode
- Improved error message to include elapsed time: "timeout or connection closed after Xs"
- Added timeout-specific log when timeout is reached (before abort)
**Evolutions:**
- Better observability with elapsed time in all logs
- More detailed error information (errorName, errorCode) for diagnosis
- Timeout log helps distinguish timeout from early connection closure
**Pages affectées:**
- api-filigrane/src/routes/watermark.js: Increased timeout, added timing and enhanced logging
- fixKnowledge/api-filigrane-anchor-request-aborted.md: Updated documentation with new timeout (180s), improved logging details, and mutex wait explanation
