Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status endpoint returns incomplete information about the last indexed block #1516

Closed
tk-o opened this issue Feb 13, 2025 · 2 comments · Fixed by #1530
Closed

Status endpoint returns incomplete information about the last indexed block #1516

tk-o opened this issue Feb 13, 2025 · 2 comments · Fixed by #1530

Comments

@tk-o
Copy link
Contributor

tk-o commented Feb 13, 2025

Version

0.9.10

Current behavior

GET /status mostly return incomplete information about the last processed block:

{"8453":{"block":null,"ready":false},"59144":{"block":{"number":6692961,"timestamp":1720789138},"ready":false}}

Sometime the response is complete, including the last processed block information:

{"8453":{"block":{"number":17778813,"timestamp":1722346973},"ready":false},"59144":{"block":{"number":7471797,"timestamp":1722347010},"ready":false}}

Expected behavior

GET /status always returns a complete response, including the last processed block information (block number, block timestamp), for example:

{"8453":{"block":{"number":17778813,"timestamp":1722346973},"ready":false},"59144":{"block":{"number":7471797,"timestamp":1722347010},"ready":false}}

Steps to reproduce

  1. For a running indexer service, send HTTP request to GET /status endpoint on your running indexer service.
  2. Observe the response.

Link to repository

https://github.com/namehash/ensnode/tree/main/apps/ensnode

Anything else?

I have been running two services with [email protected], feel free to get these nodes' status at:

@kyscott18
Copy link
Collaborator

Hey @tk-o thanks for opening this. Have you noticed that the /status response reverts from having block information to have no block information for a network? At the beginning of indexing, Ponder is unable to determine what block the most recently indexed event is in until an event occurs in that network.

@tk-o
Copy link
Contributor Author

tk-o commented Feb 14, 2025

Hard to say, but I remember, that while on v0.9.2 I could see status info loaded very quickly and being updated often enough for my use case.

What's interesting, /metrics enpodint serves correct data while /status endpoint does not.

Two tests:

curl -s https://alpha.ensnode.io/metrics | grep 'ponder_sync_block{' && curl -s https://alpha.ensnode.io/status
curl -s https://subgraph.ensnode.io/metrics | grep 'ponder_sync_block{' && curl -s https://subgraph.ensnode.io/status

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants