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

return 500 status codes properly when a Stacks block could not be ingested #646

Closed
rafaelcr opened this issue Oct 2, 2024 · 1 comment · Fixed by #648
Closed

return 500 status codes properly when a Stacks block could not be ingested #646

rafaelcr opened this issue Oct 2, 2024 · 1 comment · Fixed by #648
Assignees
Labels
bug Something isn't working released on @stacks-signers

Comments

@rafaelcr
Copy link
Collaborator

rafaelcr commented Oct 2, 2024

The HTTP server that consumes data from the Stacks node always returns a 200 status code regardless if the block has been ingested correctly or not, because the response handlers never actually return an error, the error is only reflected in the body:

return Json(json!({
    "status": 500,
    "result": format!("Unable to standardize stacks block {}", e),
}));

Because of this, the Stacks node continues to advance the chain creating gaps in the index that are impossible to recover from. This is related to #623

@rafaelcr rafaelcr added the bug Something isn't working label Oct 2, 2024
@rafaelcr rafaelcr self-assigned this Oct 2, 2024
@github-project-automation github-project-automation bot moved this to 🆕 New in DevTools Oct 2, 2024
@rafaelcr rafaelcr moved this from 🆕 New to 🏗 In Progress in DevTools Oct 2, 2024
rafaelcr added a commit that referenced this issue Oct 8, 2024
…#648)

This PR makes sure we return a `500` status code error to the Stacks
node when chainhook failed to ingest an event correctly, so it can retry
indefinitely until it succeeds.

This prevents block gaps from occurring in the chainhook index.

Fixes #646
@github-project-automation github-project-automation bot moved this from 🏗 In Progress to ✅ Done in DevTools Oct 8, 2024
github-actions bot pushed a commit that referenced this issue Oct 25, 2024
## [1.9.0-stacks-signers.1](v1.8.0...v1.9.0-stacks-signers.1) (2024-10-25)

### Features

* add various new nakamoto block fields to `/new_block` ingestion and `StacksPayload` ([#659](#659)) ([f48cda5](f48cda5))
* include recovered signer pubkeys in new block payload ([#662](#662)) ([b5ad4ba](b5ad4ba))
* include signer messages in Stacks predicate payloads ([#656](#656)) ([aee14bc](aee14bc))
* parse `/stackerdb_chunks` Stacks node event ([#653](#653)) ([e44d84a](e44d84a))
* store signer messages in local sqlite database ([#664](#664)) ([d12acd9](d12acd9))
* support tenure-height in block messages ([#661](#661)) ([99e5a61](99e5a61))
* **ts-client:** add persisted predicates and periodic health check ([#658](#658)) ([535226a](535226a))
* **ts-client:** add signer messages to stacks payloads ([#657](#657)) ([ff66bb2](ff66bb2))

### Bug Fixes

* add a configurable max timeout for outgoing predicate payload requests ([#642](#642)) ([6c1dfa9](6c1dfa9)), closes [#643](#643)
* increase stacks event server body size limit to 500MB ([#660](#660)) ([21234c9](21234c9))
* return 500 status code to Stacks node when event ingestion fails ([#648](#648)) ([63c753c](63c753c)), closes [#646](#646)
* signer pubkey calculation ([#665](#665)) ([cc93873](cc93873))
* update SignerMessage deserializing ([#663](#663)) ([71364c1](71364c1))
* validate ts client predicates before registering ([#639](#639)) ([2d08f72](2d08f72))
Copy link

🎉 This issue has been resolved in version 1.9.0-stacks-signers.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working released on @stacks-signers
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant