Skip to content

fix(protocols): ProtocolBase.pack() without keywords replaces the instance's header #1769

Closed

Description

@JarryShaw

Describe the bug
ProtocolBase.pack() with no keywords rebuilds through make() with defaults, as the #1103 sweep now documents. It also replaces the instance's own header, which leaves the instance disagreeing with itself:

u = UDP(srcport=1234, dstport=53)
u.data     # 04d2003500080000
u.pack()   # 0000000000080000
u.schema.srcport  # 0 (reserved), while u.info.srcport is still 1234

Expected behavior
pack() should not change the parsed or constructed state of the instance it is called on. Afterwards, schema and info should still describe the same packet.

Additional context

Activity

  1. added
    fixPull requests that fix a defect (fix: subject prefix)
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    on Oct 15, 2026
  2. JarryShaw commented on Oct 15, 2026

    @JarryShaw
    OwnerAuthor

    Needs a decision between the two options in the body:

    • (A) Recommended. pack() with no keywords builds a fresh header but does not assign it, so the instance keeps the state it was parsed or constructed with.
    • (B) Keep the current behaviour and document the mutation.

    A is the smaller contract: calling pack() never changes the packet it is called on. Waiting on your call before any work starts.

  3. JarryShaw commented on Oct 15, 2026

    @JarryShaw
    OwnerAuthor

    take A

  4. JarryShaw commented on Oct 15, 2026

    @JarryShaw
    OwnerAuthor

    Recorded: option A. With no keywords, pack() builds a fresh header and does not assign it to the instance. The instance keeps the state it was parsed or constructed with, so schema and info keep agreeing. A test pins this.

    Work starts once the #1103 round-2 slice that is editing protocol.py lands, to avoid a conflict.

  5. added
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    and removed
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    on Oct 15, 2026
  6. moved this to Pending in PyPCAPKiton Oct 15, 2026
  7. JarryShaw commented on Oct 15, 2026

    @JarryShaw
    OwnerAuthor

    Blocked until #1765 and the #1103 round-2 application PR merge. Both edit pcapkit/protocols/protocol.py. Relabelled from pending to blocked to match.

  8. added
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    and removed
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    on Oct 15, 2026
  9. moved this from Pending to Blocked in PyPCAPKiton Oct 15, 2026
  10. JarryShaw commented on Oct 15, 2026

    @JarryShaw
    OwnerAuthor

    #1765 has merged. Still blocked, now on #1785 alone (the round-2 application PR, which edits pcapkit/protocols/protocol.py).

  11. JarryShaw commented on Oct 15, 2026

    @JarryShaw
    OwnerAuthor

    Unblocked: #1785 has merged. A worker is on option A.

  12. 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 15, 2026
  13. moved this from Blocked to WIP in PyPCAPKiton Oct 15, 2026
  14. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 15, 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

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions