Un issue cerrado no es un fix. El comentario de cierre lo escribe alguien que cree haberlo arreglado, y muchas veces lo arregló en el camino que probó, no en el que reportaste.
Entre el 14 de octubre y el 4 de noviembre reporté cuatro bugs en el tracker público de 8004scan. Los cuatro están cerrados. Esto es lo que encontré y cómo verifiqué cada uno.
1. El endpoint MCP no completaba el handshake
POST /api/v1/mcp devolvía 405 Method Not Allowed con allow: GET, HEAD. El cliente SSE abría con 200 y se quedaba en silencio: ni evento endpoint, ni ping, ni un byte en 25 segundos. En mainnet y en testnet.
Eso rompe cualquier cliente MCP: lo primero que manda es initialize, y va por POST.
La verificación es la misma petición que fallaba:
curl -i -X POST https://api.8004scan.io/api/v1/mcp \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}' Responde 200 con serverInfo y las capacidades. Tardó 605 ms en mainnet y 546 ms en testnet.
2. El historial de entregas daba 500
GET /api/v1/webhooks/{id}/deliveries devolvía 500 con un JWT de dueño válido y un webhook activo. No había forma de saber si un evento se entregó, ni por qué falló.
Ahora responde 200 en los dos hosts, y el objeto trae lo que faltaba: event_type, status, attempts, last_attempt_at y response_status.
3. Borrar un webhook daba 500 y lo dejaba vivo
DELETE /api/v1/webhooks/{id} devolvía 500 DATABASE_ERROR y el webhook seguía con active: true. Solo se podían agregar, nunca quitar. Cuando cambia la URL que recibe, la vieja sigue recibiendo para siempre.
Ahora responde 200 con {"success":true,"message":"Webhook deleted"}. La lista pasó de dos webhooks a uno, y el historial del borrado da 404: se va con él.
El cuarto lo cerré yo
El issue de métricas de wallet lo cerré yo, no ellos. Era su pipeline, no un bug reproducible de mi lado. Vale decirlo, porque un tracker con issues abiertos que ya no aplican también es ruido.
Lo que me llevo
Repetir la petición exacta, no una parecida. Un 405 se comprueba con el mismo POST y el mismo header Accept. Un GET que ahora funciona no dice nada.
Probar los dos hosts. Los reportes eran de mainnet y testnet, y el arreglo podía haber llegado a uno solo.
Mirar los efectos, no solo el código de estado. Que el DELETE devuelva 200 no dice si borró. Hay que volver a listar. Y si el recurso tenía historial, hay que ver qué pasó con él.
Y una trampa que encontré de paso: si rotas el secreto de firma al registrar un webhook nuevo, el anterior queda firmado con el secreto viejo. Sigue activo, sigue recibiendo, y falla con 401 en cada entrega. Con un solo secreto compartido, dos webhooks activos no pueden convivir. Hay que borrar el viejo, no solo agregar el nuevo.
Los cuatro reportes están en alt-research/8004scan-issue-tracker.
