ITADN

cl/sentinel/communication/ssz_snappy: DecodeAndRead's TODO points at a closed, unrelated issue

#22817Openyperbasis 创建于 23 天前
tech debt reductionCaplin
Y
yperbasiscommented
## 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 条评论