Bug Report: api container sends abci_query with height: 0 despite being synced #435
Bug Report: api container sends abci_query with height: 0 despite being synced Title: api container sends abci_query for EpochInfo with "height":"0", causing requests to /v1/epochs/current/participants to fail.
Description: Hello, I am running a node following the official deployment guide. My node container is fully synced with the mainnet. However, the api container is unable to correctly fetch epoch information, because it sends RPC requests to the node with height: 0, even though it knows the correct current height.
Environment:
Deployment: Docker Compose (docker-compose.yml and docker-compose.mlnode.yml)
Server: Ubuntu 22.04
Images: Using default/latest tags as per the official guide.
Steps to Reproduce:
Set up the node according to the join deployment guide.
Wait for the node container to fully sync (catching_up: false).
Observe the api container logs. It correctly logs the current block height on new blocks.
Make a GET request to the api endpoint: http://81.27.97.154
:8000/v1/epochs/current/participants.
Expected Result: The API should return a JSON object with the current epoch participants, as described in the documentation.
Actual Result: The API returns a JSON error: json
Root Cause Analysis & Proof:
I have performed a tcpdump on the internal Docker network to trace the communication between the api container (172.18.0.7) and the node container (172.18.0.6).
1. The api container CORRECTLY gets the sync status:
The api container sends a status request and receives a correct response with the current height.
- Request from
api: - Response from
node:```json {"jsonrpc":"2.0", "id":0, "result":{ ... "sync_info":{"latest_block_height":"1287647", ... "catching_up":false}, ... }}
2. The api container INCORRECTLY queries for epoch info:
Immediately after, when processing the external request, the api container sends an abci_query but erroneously uses "height":"0" in the parameters.
- Faulty Request from
api:json{"jsonrpc":"2.0", "id":333, "method":"abci_query", "params":{"data":"", "height":"0", "path":"/inference.inference.Query/EpochInfo", "prove":false}} ```
This proves that the api container is aware of the correct block height but fails to use it in subsequent critical queries, causing the failure. This appears to be a bug within the api client itself.
Could you please advise on which version/tag of the gonka/api image is stable and does not have this bug? Or is there a known workaround?
Thank you.
*
💬 Comments (2)
Re-triaged this while sweeping older issues — it appears this is fixed on current main, though not by #681.
The code path that produced the reported behavior (the Tendermint-RPC based participants handler using cosmosclient.QueryByKey with height 0 and no fallback) was deleted wholesale by the Devshard 0.2.14 v4 merge (#1482, b53fd8fcd, 2026-07-25). On current main, /v1/epochs/current/participants is served by the shared common/queryapi handlers (common/queryapi/epoch.go, getEpochParticipants): the current value is read via gRPC CometServiceClient().ABCIQuery at height 0 (which per ABCI semantics means "latest committed state" — correct for a synced node), and the proof is then re-queried at an explicit historical height (proofHeight = activeParticipants.CreatedAtBlockHeight). That is structurally the "use an explicit height for provable reads" behavior #681 was after, so #681 is superseded as well.
Since the vulnerable code no longer exists, the originally reported failure can't occur on current main. This issue can probably be closed as fixed by the #1482 refactor — unless the reporter can still reproduce it on a ≥0.2.14 deployment, in which case fresh logs would be needed.
🔄 Auto-synced from Issue #435 every hour.
PR created: https://github.com/gonka-ai/gonka/pull/681
Uses current block height for ABCI queries.