Skip to content

[review-finding] DECODE_APPLY/STATE_PUT: fabricated checkpoint fallback labels pos_max=n_past-1 after full restore — mislabeled checkpoint forces re-decode of baked tokens (same mechanism as #469) #95

Description

@ddvnguyen

Finding (from QA review of PR #93, 2026-08-08)

Both restore paths (STATE_PUT :3457-3458 and now DECODE_APPLY :4628-4629) fall back to create_checkpoint(*slot, 0, 0, n_past-1) AFTER the full n_past-token state is already restored. The registered checkpoint's snapshot actually contains n_past tokens but is labeled pos_max = n_past - 1.

Impact

Traced consumer: update_slots checkpoint search (:6357/:6387). If the mislabeled checkpoint gets matched on a second decode turn on the same slot, it forces re-decode of a token already baked into the recurrent state — the same mechanism as previously-confirmed ggml-org#469 corruption. Risk is already documented in-repo (:6489-6493).

Suggested fix (fast-follow)

When has_chkpt == false, leave slot->prompt.checkpoints EMPTY instead of fabricating a mislabeled checkpoint — fails safe (forced re-prefill) instead of failing corrupt. Applies to BOTH call sites (STATE_PUT + DECODE_APPLY).

Status

Non-blocking for PR #93 (which strictly improves the status quo — DECODE_APPLY previously dropped the checkpoint entirely). Follow-up for epic 470.

Activity

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

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions