**Motivations :** * transaction_id doit être un identifiant de transaction Bitcoin consultable sur mempool * Les UUID n'ont pas d'utilité pour identifier une transaction Bitcoin * Simplification de l'architecture en supprimant la logique de queue inutile **Root causes :** * transaction_id était généré comme UUID au lieu d'utiliser le txid Bitcoin * Logique de queue/job complexe pour gérer des identifiants temporaires * Réponse HTTP 202 alors que la transaction est créée immédiatement **Correctifs :** * transaction_id est maintenant directement le txid Bitcoin (64 hex) * Suppression complète de la logique de queue et de job (Map, cleanup, etc.) * Création immédiate de la transaction Bitcoin dans enqueue() * getStatus() interroge directement Bitcoin au lieu d'une Map en mémoire * Réponse HTTP 200 OK au lieu de 202 Accepted * Suppression de la dépendance uuid (plus utilisée) **Evolutions :** * API simplifiée : plus de queue, transactions créées directement * transaction_id consultable immédiatement sur mempool * Documentation complète des réponses JSON (API_RESPONSES.md) * Scripts de test mis à jour pour valider le format txid Bitcoin **Page affectées :** * src/services/AnchorQueueService.ts : refactor complet, suppression queue * src/controllers/AnchorController.ts : mise à jour pour txid, status 200 * src/index.ts : suppression cleanup périodique * test-api-ok.sh : validation format txid, status 200 * test-api.sh : validation format txid, status 200 * README.md : mise à jour exemples avec txid Bitcoin * API_RESPONSES.md : nouvelle documentation complète des réponses JSON
493 B
493 B
Note de Déploiement
⚠️ IMPORTANT: Ce dossier lecoffre-anchor-api NE DOIT PAS être déployé par deploy-remote.sh.
Pourquoi ?
- Ce dossier est déployé sur le serveur :
dev3.4nkweb.com(node Bitcoin) - Le backend principal (
lecoffre-back-main) et le frontend (lecoffre-front-main) sont surlocal.4nkweb.com - L'API d'ancrage nécessite un accès direct au nœud Bitcoin Signet
Déploiement
Utiliser le script dédié:
./deploy-anchor-api.sh