Proposed worksheet · Method notes updated 11 November 2026 · Not independently tested

The decision

Check the server capability and bind responses to the exact current interrupt ID.

Use this guide with your own evidence

The draft includes this method’s reference and proposed checks. Confirm they fit your task, then add your authorized scope and observations. No checks have been run.

Start a JSON recordStart a Markdown record

Use this when

A LangGraph workflow pauses for input and can receive retries, multiple-tab responses, or successive answers.

Skip this when

Your workflow never resumes paused input. RemoteGraph and local-runtime paths need their own documented behavior.

Work through the checks

  1. Separate the three surfaces

    The primary-source review identifies strict_resume in Python async and sync langgraph-sdk 0.4.14 thread runs.create, runs.stream and runs.wait. Stateless calls omit it. Keep the public SDK parameter, server capability and separate local-runtime private key distinct. A client argument is not proof of server enforcement.

  2. Read current state

    Read the live interrupt ID from the authoritative server state or stream. Do not derive it from a task title or reuse an older answer’s ID. Keep the current question visible in the interface.

  3. Rehearse stale and fresh answers

    Create harmless question A followed by B. Answer A, read B’s new ID, then replay A’s saved response. Confirm B remains pending. Answer B with its current ID and confirm the valid path succeeds.

  4. Make absence visible

    Test unknown IDs and unsupported-server behavior separately. Check the deployed server’s /info response for strict_resume support. The reviewed SDK change says unsupported servers can ignore the field. Mark enforcement unavailable rather than interpreting request success as protection.

What would count as success?

  1. A stale answer never advances the current question. Evidence for check 1
  2. Rejection is visible and the user can re-read and answer the current question. Evidence for check 2
  3. A fresh valid answer still works. Evidence for check 3

Evidence to bring back

Proposed evidence plan, not observed results or extra mandatory process. Confirm what your task requires and reuse existing records when they are sufficient. Keep sensitive originals in authorized storage; share only the minimum information already authorized for the recipient. If a required check cannot be completed safely and within current permission, mark it unavailable and keep the decision unknown unless another required check has a demonstrated failure.

  1. A stale answer never advances the current question.

    Proposed evidence for acceptance check 1. No result has been observed here.

    Bring back: Keep the authoritative interrupt IDs and state before and after replaying the stale A response while B is pending. Record whether B remains pending and whether any downstream effect occurred.

    Not enough: A stale-answer error alone without inspecting the current state or downstream effect.

  2. Rejection is visible and the user can re-read and answer the current question.

    Proposed evidence for acceptance check 2. No result has been observed here.

    Bring back: Keep the stale/unknown-ID rejection result and the subsequent read that exposes the current question and ID. Record whether the intended user can reach that recovery path within existing access.

    Not enough: A backend log entry that gives the user no route to recover the current question.

  3. A fresh valid answer still works.

    Proposed evidence for acceptance check 3. No result has been observed here.

    Bring back: Record a fresh valid B response and its expected state transition on the same deployed configuration. Retain the relevant /info capability response; if enforcement is unsupported or cannot be checked, leave the protection claim unknown.

    Not enough: A successful HTTP request or an SDK argument without confirming the expected state transition and server capability.

Stop or recover

Pause the resume path if the binding is uncertain. Retain checkpoint and answer records. Do not automatically replay old answers after a rollback.

What this does not establish

The specific SDK and runtime changes were rechecked against primary sources on 10 November 2026, but no real LangGraph server was executed for this reconstruction. These are bounded acceptance recipes, not measured results or a complete authorization policy.

Reference links

Links checked 10 November 2026. Each note below states what the reference supports. No source review validates this worksheet’s effectiveness or replaces testing in your environment.

  • langgraph-sdk 0.4.14

    Primary SDK release record. A client version does not establish server-side enforcement.

  • Public SDK strict_resume support

    Primary change defining strict_resume on Python async/sync thread runs and the server capability limitation.

  • Runtime strict resume change

    Primary runtime change for strict resume checks. Separate from SDK argument availability and not a complete authorization policy.

Take this worksheet with you

Section links identify this page, not an immutable copy. Numbered checks may change in later revisions. For an exact reference, retain build revision release-2026-11-11-r12 and the method source hash in the JSON or Markdown version.

This guide’s draft recordHow to complete a recordRead MarkdownRead JSON