fix(legion): parse the real Chainhooks 2.0 payload shape - #891
Merged
Conversation
The receiver was written against classic Chainhook and matched none of the
2.0 delivery format, so every delivery parsed to zero events. Worse, it did
so silently: the handler returned 200, Chainhooks recorded six healthy
occurrences, and nothing was ever indexed.
Five differences, taken from the SDK's own TypeBox schemas rather than the
docs:
apply/rollback live under `event`, not at the top level
per-tx events are `operations`, not `metadata.receipt.events`
the print type is `contract_log`, not `SmartContractEvent`
fields hang off `metadata`, not `data`
failure is `metadata.status !== "success"`, not `metadata.success === false`
Event values are also normalised three ways — already-decoded object,
{hex, repr}, or a bare hex string — falling back to the local Clarity codec
so indexing does not depend on the service honouring decode_clarity_values.
A delivery that parses to zero events now logs a warning, since that is
exactly how this failure hid.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
|
Preview deployed: https://agent-news-staging.hosting-962.workers.dev This preview uses sample data — beats, signals, and streaks are seeded automatically. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The chainhook receiver in #890 was written against classic Chainhook's payload format. Chainhooks 2.0 differs in five places, and every one of them fails silently — the parser finds zero events, returns 200, and the service records a healthy delivery while nothing is indexed.
Caught in production: hook
f0f6a9bcreportedstatus: streaming, occurrence_count: 6with an empty database.What differs
Taken from
@stacks/chainhooks-client's TypeBox schemas rather than the docs:payload.applypayload.event.applytx.metadata.receipt.eventstx.operationstype: "SmartContractEvent"type: "contract_log"ev.data.*op.metadata.*metadata.success === falsemetadata.status !== "success"Also
Event values are normalised three ways — already-decoded object,
{hex, repr}, or a bare hex string — falling back to the local Clarity codec. Indexing no longer depends on the service honouringdecode_clarity_values.A delivery parsing to zero events now logs a warning. That silence is precisely how this hid.
Tests
Three regression tests built on a delivery shaped to the real schema: nested extraction, contract filtering, and hex fallback. Also asserts an
abort_by_post_conditiontransaction is skipped — an abortedconcludemust never render as a conclusion that happened.502 tests passing.