ncantu 8662e9e584 Optimize anchor API performance and fix request abort issues

**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

2026-01-28 11:38:43 +01:00

2.6 KiB

Raw Permalink Blame History

UserWallet – Validation stricte CNIL

Author: Équipe 4NK
Date: 2026-01-28

Objectif

Implémenter la validation stricte CNIL pour les contrats et champs, permettant de transformer les warnings en erreurs selon la politique métier.

Motivations

Conformité CNIL stricte selon la politique métier
Possibilité d'activer/désactiver la validation stricte
Bloquer l'utilisation des contrats/champs non conformes CNIL en mode strict

Modifications

`src/utils/cnilValidation.ts`

Ajout de CNILValidationPolicy pour configurer la validation
Ajout de DEFAULT_CNIL_POLICY (mode non strict par défaut)
Ajout de STRICT_CNIL_POLICY (mode strict avec tous les champs requis)
Extension de validateCNILFields() pour accepter une politique
Extension de validateContractCNIL() pour accepter une politique
Extension de validateChampCNIL() pour accepter une politique
Ajout de getCNILPolicy() pour récupérer la politique depuis le localStorage
Ajout de setCNILPolicy() pour stocker la politique

`src/services/graphResolver.ts`

Mise à jour de addContrat() pour utiliser getCNILPolicy()
Mise à jour de addChamp() pour utiliser getCNILPolicy()
Rejet des contrats/champs non conformes en mode strict (suppression du cache)

Utilisation

Mode par défaut (non strict)

import { validateContractCNIL, DEFAULT_CNIL_POLICY } from './utils/cnilValidation';

const validation = validateContractCNIL(contrat, DEFAULT_CNIL_POLICY);
// Génère des warnings mais n'échoue pas

Mode strict

import { validateContractCNIL, STRICT_CNIL_POLICY } from './utils/cnilValidation';

const validation = validateContractCNIL(contrat, STRICT_CNIL_POLICY);
// Génère des erreurs si les champs CNIL sont manquants
if (!validation.valid) {
  // Contrat rejeté
}

Configuration personnalisée

import { setCNILPolicy, getCNILPolicy } from './utils/cnilValidation';

// Activer le mode strict
setCNILPolicy(STRICT_CNIL_POLICY);

// Récupérer la politique actuelle
const policy = getCNILPolicy();

Politique métier

La politique CNIL peut être configurée via :

strict: Mode strict (warnings → errors)
requireRaisonsUsageTiers: Require raisons_usage_tiers
requireRaisonsPartageTiers: Require raisons_partage_tiers
requireConditionsConservation: Require conditions_conservation

En mode strict, les contrats/champs non conformes sont rejetés et retirés du cache du graphe.

Références

features/userwallet-champs-obligatoires-cnil.md
userwallet/docs/specs-champs-obligatoires-cnil.md

2.6 KiB Raw Permalink Blame History Unescape Escape