# Fix: Anchor API request failed (BLOQUANT) – "This operation was aborted"

**Auteur** : Équipe 4NK
**Date** : 2026-01-28
**Version** : 1.0

## Problème identifié

Lors du traitement de documents (filigrane + ancrage), l’appel à l’API d’ancrage échoue avec une erreur de type :

- `Anchor API request failed (BLOQUANT): This operation was aborted.`
- `[FileProcessingService] ÉCHEC ANCRAGE BITCOIN pour document <uuid>`
- Le document n’est pas créé car l’ancrage est bloquant.

### Symptômes

- Erreur systématique ou intermittente sur l’ancrage.
- Message natif : `This operation was aborted` (DOMException lorsque la requête HTTP est interrompue).
- Les messages « FileProcessingService », « Anchor API request failed (BLOQUANT) », « ÉCHEC ANCRAGE BITCOIN » sont émis par le client (frontend ou service appelant la chaîne filigrane → ancrage), pas par ce dépôt.

## Cause racine

La requête HTTP envoyée par **api-filigrane** vers l’API d’ancrage (`https://anchorage.certificator.4nkweb.com/api/anchor/document`) est **interrompue** avant d’avoir reçu une réponse. Causes possibles :

1. **Timeout côté proxy (nginx / reverse proxy)**  
   Si `proxy_read_timeout` (ou équivalent) est trop court, le proxy ferme la connexion pendant que l’ancrage est encore en cours (RPC Bitcoin, construction tx, broadcast). La fermeture de la connexion provoque l’abort du `fetch()` côté api-filigrane → « This operation was aborted ».

2. **Absence de timeout explicite côté api-filigrane**  
   Le `fetch()` vers l’API d’ancrage n’avait ni `AbortSignal` ni timeout. En cas de fermeture de connexion (proxy, réseau, serveur anchorage), Node renvoie une erreur d’abort sans message explicite sur la cause (timeout proxy vs indisponibilité anchorage).

3. **Durée réelle de l’ancrage**  
   `api-anchorage` exécute : lecture DB UTXOs, mutex, RPC bitcoind (listunspent, createrawtransaction, sign, send). Sous charge ou latence RPC, la réponse peut dépasser 30–60 s, ce qui dépasse souvent les timeouts proxy par défaut.

4. **Attente du mutex**  
   Si plusieurs ancrages sont en cours simultanément, les requêtes doivent attendre le mutex pour accéder aux UTXOs. Cette attente peut faire dépasser le timeout de 120s, surtout si les opérations RPC Bitcoin sont lentes.

## Correctifs appliqués

### 1. Timeout et gestion d’erreur dans api-filigrane (`callAnchorAPI`)

**Fichier** : `api-filigrane/src/routes/watermark.js`

- **Timeout explicite** : `AbortController` avec un timeout de 120 s (`ANCHOR_API_TIMEOUT_MS = 120000`) pour l’appel à l’API d’ancrage. Évite d’attendre indéfiniment et permet de distinguer un vrai timeout d’une simple fermeture de connexion.
- **Gestion des aborts** :  
  Si l’erreur est de type abort (`AbortError` ou message contenant « aborted »), on log et on relance une erreur explicite :  
  `Anchor API request aborted: timeout or connection closed. Check anchorage availability and proxy read timeout (e.g. 120s).`
- **Logs** :  
  En cas d’abort ou d’échec, log avec `url`, `documentUid` et `message` pour le diagnostic (disponibilité anchorage, timeouts proxy).

### 2. Recommandation infrastructure (proxy)

Pour que l’ancrage ne soit pas coupé par le proxy :

- **Nginx** (ou équivalent) devant `api-anchorage` :  
  `proxy_read_timeout` et `proxy_connect_timeout` ≥ 180 s pour les routes d’ancrage (au minimum `POST /api/anchor/document`). Le timeout nginx doit être supérieur ou égal au timeout côté api-filigrane (180s).
- Exemple (à adapter au bloc `location` concerné) :
  ```nginx
  proxy_read_timeout 180s;
  proxy_connect_timeout 75s;
  proxy_send_timeout 180s;
  ```

## Modifications

**Fichiers modifiés**

- `api-filigrane/src/routes/watermark.js` : 
  - Constante `ANCHOR_API_TIMEOUT_MS` augmentée de 120000 (120s) à 180000 (180s)
  - `AbortController` + timeout sur le `fetch`
  - Gestion des aborts avec temps écoulé dans le message d'erreur
  - Logs améliorés avec temps de début, temps écoulé, détails d'erreur (`errorName`, `errorCode`)
  - Log au début de la requête, en cas de succès, d'abort et d'échec

**Fichiers créés**

- `fixKnowledge/api-filigrane-anchor-request-aborted.md` : cette documentation.

## Modalités de déploiement

1. **Déployer la nouvelle version de api-filigrane** (contenant le timeout 180 s et la gestion d’erreur améliorée).
2. **Vérifier / ajuster le reverse proxy** devant api-anchorage :
   - Timeouts ≥ 180 s pour les requêtes vers l’API d’ancrage (le timeout nginx doit être supérieur ou égal au timeout côté api-filigrane).
3. **Redémarrer api-filigrane** après déploiement.
4. **Tester** : soumettre un document (filigrane + ancrage) et vérifier les logs api-filigrane en cas d’échec (message « Anchor API request aborted » ou « Anchor API request failed » avec url/documentUid/elapsedMs).

## Modalités d’analyse

- **Logs api-filigrane** :  
  Rechercher `Anchor API request aborted` ou `Anchor API request failed` avec l’URL, le `documentUid` et le `elapsedMs` pour savoir si l’échec est lié au timeout 180s ou à une fermeture de connexion avant (proxy, réseau). Le `elapsedMs` indique le temps écoulé avant l’abort, ce qui permet de distinguer un timeout (≈180s) d’une fermeture de connexion précoce.
- **Logs api-anchorage** :  
  Vérifier que les requêtes `POST /api/anchor/document` arrivent bien et si elles sont longues (RPC, mutex). Si les requêtes n’apparaissent pas ou sont coupées après X secondes, augmenter les timeouts proxy. Vérifier aussi les logs de mutex pour voir s’il y a des attentes longues.
- **Logs proxy (nginx)** :  
  En cas de fermeture de connexion côté proxy, les logs nginx (erreur, timeout) indiquent si la coupure vient du proxy. Vérifier que `proxy_read_timeout` est ≥ 180s.

## Références

- Message d’erreur utilisateur : `Anchor API request failed (BLOQUANT): This operation was aborted.`
- Erreur native : `DOMException` / « This operation was aborted » lorsque `fetch()` est interrompu (connexion fermée ou `AbortController.abort()`).
- Documentation existante : `fixKnowledge/api-anchorage-401-error.md`, `fixKnowledge/api-anchorage-too-long-mempool-chain.md`.