8662e9e584
**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
64 lines
2.1 KiB
Markdown
64 lines
2.1 KiB
Markdown
# UserWallet – Notifications relais étendues
|
||
|
||
**Author:** Équipe 4NK
|
||
**Date:** 2026-01-28
|
||
|
||
## Objectif
|
||
|
||
Étendre le système de notifications relais pour réagir à d'autres événements relais (push, etc.) et détecter différents types d'objets (signatures, contrats, membres, pairs, actions, champs).
|
||
|
||
## Motivations
|
||
|
||
- Réagir aux événements push si extension (ex. WebSocket)
|
||
- Détecter automatiquement le type d'objet (signatures, contrats, membres, pairs, actions, champs)
|
||
- Optimiser le fetch selon le type d'objet détecté
|
||
- Mettre à jour le graphe en conséquence
|
||
|
||
## Modifications
|
||
|
||
### `src/services/relayNotificationService.ts`
|
||
|
||
- Ajout du type `RelayObjectType` pour identifier les types d'objets
|
||
- Extension de `RelayHashEvent` avec `objectType` et `source` (polling/push/manual)
|
||
- Ajout de `detectObjectType()` pour détecter le type depuis le message déchiffré
|
||
- Ajout de `processHashByType()` pour optimiser le traitement selon le type
|
||
- Extension de `triggerHashProcessing()` pour supporter le type d'objet
|
||
- Amélioration de `startPolling()` pour inclure le type dans les événements
|
||
|
||
### `src/hooks/useRelayNotifications.ts`
|
||
|
||
- Mise à jour du listener pour utiliser `processHashByType()` si le type est connu
|
||
- Logging amélioré avec le type d'objet et la source
|
||
|
||
## Utilisation
|
||
|
||
Le système détecte automatiquement le type d'objet lors du traitement d'un hash. Les notifications peuvent maintenant spécifier le type :
|
||
|
||
```typescript
|
||
// Traitement manuel avec type spécifié
|
||
await notificationService.triggerHashProcessing(
|
||
hash,
|
||
relay,
|
||
options,
|
||
'contrat' // type d'objet
|
||
);
|
||
|
||
// Traitement optimisé par type
|
||
await notificationService.processHashByType(
|
||
hash,
|
||
'signature', // type d'objet
|
||
options
|
||
);
|
||
```
|
||
|
||
## Évolutions futures
|
||
|
||
- Support WebSocket pour les événements push en temps réel
|
||
- Détection automatique du type depuis les métadonnées publiques (datajson)
|
||
- Optimisation du fetch selon le type (ex. pas besoin de clés pour les signatures)
|
||
|
||
## Références
|
||
|
||
- `features/userwallet-notifications-relais.md`
|
||
- `features/userwallet-contrat-login-reste-a-faire.md` (§ 3.2)
|