anchorage_layer_simple/fixKnowledge/api-filigrane-anchor-request-aborted.md

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é) :

  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.