Skip to content

fix(schema): a SchemaField's unread octets are lost through from_data, so a direct SchemaField rebuilds zero-filled #1380

Closed

Description

@JarryShaw

Split from #1292 after the #1374 cross-review. #1374 makes a directly declared SchemaField pack its whole declared span, so the parse → pack round trip is byte-exact: 0302eeee04 rebuilds as 0302eeee04. The parse → from_data round trip still loses the unread octets. Out2.from_dict(o.to_dict()).pack() gives 0302000004. The length is consistent, but the octets the inner schema did not read are zero-filled.

The cause is that Protocol.from_data (protocols/protocol.py:799-847) runs Data.from_dict → _make_data → __init__ → make. That path builds a fresh schema that was never unpacked, so there are no unread octets to re-emit, and the data model has no slot that carries them.

Scope: none of the 446 shipped schema classes declares a SchemaField directly or behind a static ConditionalField. Every library SchemaField sits behind a SwitchField or is a ListField item. This affects user-defined schemas only.

Fix: carry the unread remainder through the data model, e.g. a remainder key in to_dict(), and re-emit it on build, as #1344 did for IPv4 option padding and #1348 for TCP. Then update #1374's test_schema_field_keeps_declared_width, which currently pins 0302000004.

Blocked on #1374 (same schema.py).

Activity

  1. added
    fixPull requests that fix a defect (fix: subject prefix)
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 7, 2026
  2. JarryShaw commented on Oct 8, 2026

    @JarryShaw
    OwnerAuthor

    Still blocked, now on a different PR. #1374 has merged, but this fix edits Protocol.from_data in protocols/protocol.py, and #1395 (the fix that turns main green again, #1394) edits the same file. Blocked until #1395 merges.

  3. JarryShaw commented on Oct 8, 2026

    @JarryShaw
    OwnerAuthor

    Unblocked: #1395 has merged, and no open PR now edits protocols/protocol.py. A worker is starting on it.

  4. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 8, 2026
  5. added a commit that references this issue on Oct 8, 2026
    7a1e11b
  6. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 8, 2026
  7. added this to the PyPCAPKit v1.5 milestone on Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    fixPull requests that fix a defect (fix: subject prefix)

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions