Refactor Config wire serialization to eliminate parallel field lists #218

Closed
opened 2026-09-01 21:09:41 +02:00 by TapTap · 1 comment
Owner

Summary

Config has grown to roughly 100 fields (src/shared/config.h:11-129), while config_send() (src/shared/config.c:186-280) and config_receive() (src/shared/config.c:284-459) manually repeat the wire-field order and cleanup logic. The protocol order is maintained only by a comment at config.c:176-184; adding, removing, or reordering one field requires synchronized edits in multiple long functions plus version management. This is a high-risk maintenance seam for compatibility and leaks/partial-receive handling.

Scope

Introduce a single declarative field description or narrowly scoped encode/decode helpers for the negotiated configuration. Keep the wire format explicitly versioned and portable; do not change compatibility behavior accidentally. Consolidate allocation-failure cleanup so every receive failure releases the same owned fields.

Acceptance criteria

  • Each wire field has one authoritative declaration of its order/type/optional representation.
  • Send and receive cannot silently drift when a field is added or removed; compile-time or focused tests catch mismatches.
  • Round-trip tests cover all transmitted booleans, integers, sizes, and strings, including empty optional strings and truncated input.
  • Protocol versioning behavior remains explicit and existing config tests/integration tests pass.

Severity

medium

Category

quality


Automated maintainability audit; no source changes were made.

## Summary `Config` has grown to roughly 100 fields (`src/shared/config.h:11-129`), while `config_send()` (`src/shared/config.c:186-280`) and `config_receive()` (`src/shared/config.c:284-459`) manually repeat the wire-field order and cleanup logic. The protocol order is maintained only by a comment at `config.c:176-184`; adding, removing, or reordering one field requires synchronized edits in multiple long functions plus version management. This is a high-risk maintenance seam for compatibility and leaks/partial-receive handling. ## Scope Introduce a single declarative field description or narrowly scoped encode/decode helpers for the negotiated configuration. Keep the wire format explicitly versioned and portable; do not change compatibility behavior accidentally. Consolidate allocation-failure cleanup so every receive failure releases the same owned fields. ## Acceptance criteria - Each wire field has one authoritative declaration of its order/type/optional representation. - Send and receive cannot silently drift when a field is added or removed; compile-time or focused tests catch mismatches. - Round-trip tests cover all transmitted booleans, integers, sizes, and strings, including empty optional strings and truncated input. - Protocol versioning behavior remains explicit and existing config tests/integration tests pass. ## Severity medium ## Category quality --- _Automated maintainability audit; no source changes were made._
TapTap added the qualityneeds-triage labels 2026-09-01 21:09:41 +02:00
Author
Owner

Fixed. Config wire serialization is now driven by the single declarative CONFIG_WIRE_FIELDS X-macro table (src/shared/config.h), with per-segment codecs generated once (CONFIG_DEFINE_SEND/RECV in config.c). Byte-exact send/receive golden tests pin the wire frame and a full-field round-trip test catches drift. Closing as completed.

Fixed. `Config` wire serialization is now driven by the single declarative `CONFIG_WIRE_FIELDS` X-macro table (`src/shared/config.h`), with per-segment codecs generated once (`CONFIG_DEFINE_SEND/RECV` in `config.c`). Byte-exact send/receive golden tests pin the wire frame and a full-field round-trip test catches drift. Closing as completed.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: TapTap/FastSync#218