refactor: add bounded vector deserialization

[thepastaclaw]

Issue being fixed or feature implemented

Network messages often have protocol-specific vector limits below the generic serialization limit. Callers need to enforce those limits before vector allocation and element decoding, without changing the wire format.

What was done?

• Factor the existing batched vector element decoder into a shared internal helper.
• Add UnserializeVectorWithMaxSize for runtime bounds.
• Add LIMITED_VECTOR / LimitedVectorFormatter for compile-time bounds in READWRITE declarations.
• Keep serialization byte-for-byte compatible with ordinary vectors; only deserialization is bounded.
• Compare CompactSize counts before narrowing or allocating, including counts at and above MAX_SIZE.

Stacked adopters

Each consumer remains a separate command-specific PR:

• fix(net): bound quorum data response vectors #7416 — quorum-data response vectors
• fix(net): bound signing message vector intake #7418 — LLMQ signing message vectors
• fix(net): bound CoinJoin message vector intake #7419 — CoinJoin message vectors
• fix: bound SPORK signature deserialization #7438 — SPORK signature vector

Reviewing #7439 first leaves each child PR with only its protocol-specific policy, punishment, and regression tests.

How Has This Been Tested?

• src/test/test_dash --run_test=serialize_tests
• Exact and over-limit boundaries, zero limits, custom element formatters, MAX_SIZE and MAX_SIZE + 1 declarations, 64-bit CompactSize counts, wire compatibility, and rejection before element decode are covered.

Breaking Changes

None. Existing vector serialization and deserialization behavior is unchanged.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone

[kwvg]

Consider pr_7416 (especially f80422c1 9cfe87c and 6b47508d split out for review, should be squashed in final iteration)

[thepastaclaw]

Addressed in bf865ac126d. I ported the substance of f80422c1 and 6b47508d onto this branch: restored the normal CompactSize range check, documented the unrelated serialization-exception behavior, and updated the focused boundary tests. The changes are squashed into the existing single PR commit as requested; unrelated commits from pr_7416 were not brought over.

Validation: make -j15 -C src test/test_dash, ./src/test/test_dash --run_test=serialize_tests, the focused unserialize_vector_with_max_size case, and git diff --check all pass.

[thepastaclaw]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Walkthrough

The serialization framework now shares batched vector allocation and element decoding through a helper. It adds runtime maximum-size decoding and a compile-time LimitedVectorFormatter, exposed through the LIMITED_VECTOR macro. Oversized vectors are rejected before element decoding, while serialization retains the standard vector wire format. Tests cover size boundaries, malformed prefixes, failure behavior, and compatibility with unbounded vector readers.

Sequence Diagram(s)

sequenceDiagram
  participant Caller
  participant LimitedVectorFormatter
  participant Stream
  participant UnserializeVectorContents
  participant ElemFormatter
  Caller->>LimitedVectorFormatter: unserialize bounded vector
  LimitedVectorFormatter->>Stream: read CompactSize element count
  Stream-->>LimitedVectorFormatter: element count
  alt count <= Limit
    LimitedVectorFormatter->>UnserializeVectorContents: decode vector elements
    UnserializeVectorContents->>ElemFormatter: unserialize each element
    ElemFormatter-->>UnserializeVectorContents: decoded element
    UnserializeVectorContents-->>LimitedVectorFormatter: populated vector
  else count > Limit
    LimitedVectorFormatter-->>Caller: throw length-limit failure
  end

Loading

Estimated code review effort: 3 (Moderate) | ~20 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	It clearly summarizes the main change: adding bounded vector deserialization.
Description check	✅ Passed	It directly describes the implemented bounded vector deserialization features.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

✅ Review complete (commit af6a0fd)

[knst]

LGTM af6a0fd

[thepastaclaw]

Code Review

Clean, well-scoped serialization refactor adding bounded-vector deserialization primitives with byte-identical wire format and thorough unit coverage. No blocking issues: the count is validated before any allocation, the Ser side stays unbounded for wire compatibility, and CompactSize range handling is correct. One legitimate but practically-inert nitpick about formatter construction-order reordering in the refactor.

💬 1 nitpick(s)

Source: reviewers opus (general, dash-core-commit-history) and gpt-5.5 (general, dash-core-commit-history); verifier opus.

[thepastaclaw]

💬 Nitpick: Refactor reorders Formatter construction relative to clear/count-read

The pre-refactor VectorFormatter::Unser default-constructed Formatter formatter; before calling v.clear() and ReadCompactSize(s). The shared helper now constructs the Formatter inside detail::UnserializeVectorContents, after the vector is cleared and the count has been consumed from the stream. For a Formatter whose default constructor has side effects or can throw, a construction failure would now leave the stream advanced past the count and the destination vector cleared — an observable difference in a change advertised as behavior-preserving. This is inert for every formatter in the tree today (all are stateless empty structs with trivial default constructors), so it is only worth noting for the refactor's stated invariant, not a defect. If you want to preserve the exact original ordering, construct the Formatter in VectorFormatter::Unser and pass it into the shared helper by reference.

_{source: ['codex']}