cl/sentinel/communication/ssz_snappy: DecodeAndRead's TODO points at a closed, unrelated issue
tech debt reductionCaplin
## Problem
`DecodeAndRead` (`cl/sentinel/communication/ssz_snappy/encoding.go`) carries:
```go
// TODO(issues/5884): assert the fork digest matches the expectation for
// a specific configuration.
```
#5884 is closed, and it is not about this. It is a 2022 light-client question about how many prefix bytes to strip before snappy decompression, opened well before the fork-digest handling this comment annotates existed. The comment reads as a live tracking reference and is not one.
It is also in the wrong place to be actioned. `DecodeAndRead` has no non-test callers — the only ones are in `cl/sentinel/handlers/light_client_test.go` — and `DecodeListSSZ`, the other digest-consuming function in the file, has no callers at all. Every production decode in `cl/sentinel/handlers` and `cl/persistence` goes through `DecodeAndReadNoForkDigest` with a locally derived version. The live response path that actually needs this assertion is `parseResponseData` in `cl/rpc/rpc.go`, tracked in #22807.
So the one place in the tree that looks like it is tracking peer-supplied-digest validation is dead code pointing at a closed issue, while the reachable path carries no marker at all.
## Suggested resolution
Remove the TODO. Either drop `DecodeAndRead` and `DecodeListSSZ` with it and move the light-client tests to `DecodeAndReadNoForkDigest`, or keep the functions and leave no tracking comment, since the actual work is #22807. Repointing the TODO at #22807 is the minimum but still leaves it in a function the attack path never reaches.
`CLAUDE.md` asks that a TODO carry a linked tracking issue and an owner. This one has neither.
0 条评论