Description
internal/soroban/event_parser.go defines a small, self-contained payload compatibility parser:
type EventCompatPayload struct {
Version uint32 `json:"version"`
Amount int64 `json:"amount,omitempty"`
}
// ParseEventCompatPayload parses both legacy (v1, unversioned) and version-tagged payloads.
// Unknown/newer versions are accepted as long as required fields are present.
func ParseEventCompatPayload(raw []byte) (*EventCompatPayload, error) {
...
}It has its own dedicated test file (internal/soroban/event_parser_test.go) with three passing test cases (legacy v1, version-tagged v2, and forward-compat newer-version payloads). However, a repo-wide search shows ParseEventCompatPayload/EventCompatPayload are referenced nowhere outside event_parser.go and event_parser_test.go — not from internal/handlers, internal/syncjobs, internal/worker, internal/ingest, or any cmd/ entrypoint. This matches the same "implemented and unit-tested, never wired into anything that runs in production" pattern already identified elsewhere in this codebase for RepoCache/NewRepoCache and github.SetAPIBase/GetAPIBase — this is a third, distinct instance of it in the soroban package specifically, for what appears to be event-payload version-compatibility handling that no current webhook/event ingestion path actually uses.
Requirements
- Either wire
ParseEventCompatPayload into whatever code path is actually meant to consume normalized Soroban contract event payloads (if one is planned/missing), or remove the dead code if it was superseded by another mechanism.
- If retained, its intended caller and payload source (which contract events, decoded from where) must be documented so it isn't dead code with a passing test suite indefinitely.
Suggested execution
- Search
internal/soroban for where raw contract event payloads are actually decoded today (e.g. xdr_helpers.go's DecodeScValStruct family, used by getEscrowInfoRPC/getProgramInfoRPC) to determine whether EventCompatPayload was meant to normalize a different, event-stream-based ingestion path that doesn't exist yet.
- If a genuine future consumer exists (e.g. a planned webhook/event listener for on-chain contract events separate from the RPC polling this repo currently uses), wire
ParseEventCompatPayload into it and add an integration test proving the call path is exercised.
- If no such consumer is planned, remove
event_parser.go and event_parser_test.go to stop carrying maintenance cost for unreachable code, and note the removal rationale in the PR description.
Acceptance criteria
Security notes
No direct security impact; this is a maintainability/dead-code finding. Low priority relative to the other issues in this batch, but cheap to resolve either way.
Guidelines
- Minimum 95% test coverage
- Timeframe: 96 hours
Description
internal/soroban/event_parser.godefines a small, self-contained payload compatibility parser:It has its own dedicated test file (
internal/soroban/event_parser_test.go) with three passing test cases (legacy v1, version-tagged v2, and forward-compat newer-version payloads). However, a repo-wide search showsParseEventCompatPayload/EventCompatPayloadare referenced nowhere outsideevent_parser.goandevent_parser_test.go— not frominternal/handlers,internal/syncjobs,internal/worker,internal/ingest, or anycmd/entrypoint. This matches the same "implemented and unit-tested, never wired into anything that runs in production" pattern already identified elsewhere in this codebase forRepoCache/NewRepoCacheandgithub.SetAPIBase/GetAPIBase— this is a third, distinct instance of it in thesorobanpackage specifically, for what appears to be event-payload version-compatibility handling that no current webhook/event ingestion path actually uses.Requirements
ParseEventCompatPayloadinto whatever code path is actually meant to consume normalized Soroban contract event payloads (if one is planned/missing), or remove the dead code if it was superseded by another mechanism.Suggested execution
internal/sorobanfor where raw contract event payloads are actually decoded today (e.g.xdr_helpers.go'sDecodeScValStructfamily, used bygetEscrowInfoRPC/getProgramInfoRPC) to determine whetherEventCompatPayloadwas meant to normalize a different, event-stream-based ingestion path that doesn't exist yet.ParseEventCompatPayloadinto it and add an integration test proving the call path is exercised.event_parser.goandevent_parser_test.goto stop carrying maintenance cost for unreachable code, and note the removal rationale in the PR description.Acceptance criteria
ParseEventCompatPayload/EventCompatPayloadis either reachable from a real production code path with a test proving it, or removed entirely.internal/soroban/event_parser.goafter this change.Security notes
No direct security impact; this is a maintainability/dead-code finding. Low priority relative to the other issues in this batch, but cheap to resolve either way.
Guidelines