langchain-ai/langgraph
1
0
Fork 0
mirror of https://github.com/langchain-ai/langgraph.git synced 2026-07-15 12:35:43 -04:00
Code Issues 314 Packages Projects Releases 17 Wiki Activity

Lock collision-safe checkpoint key behavior for thread IDs across checkpointers #1156

New Issue
Open
opened 2026-02-20 17:43:16 -05:00 by yindo · 0 comments
yindo commented 2026-02-20 17:43:16 -05:00
Owner
Copy Link
Copy Source

Originally created by @davidahmann on GitHub (Feb 20, 2026).

Problem

Checkpoint identity must remain collision-safe in multi-tenant usage; if key derivation ever regresses toward normalized-thread-only behavior, different tenant thread IDs could alias.

Why Now

Tenant density is increasing and checkpoint correctness is a platform contract. We need explicit regression coverage so this guarantee cannot silently regress.

Current Behavior Is Insufficient

Current implementations rely on composite keying (thread_id, namespace, checkpoint id), but this safety property is not clearly enforced by dedicated collision-focused tests across checkpointers.

Why Code Change

This needs code-level contract tests and any small hardening required in key-construction paths; docs are not sufficient.

Scope / Codepaths

  • libs/checkpoint/...
  • libs/checkpoint-postgres/langgraph/checkpoint/postgres/base.py
  • libs/checkpoint-sqlite/langgraph/checkpoint/sqlite/aio.py

Acceptance / Validation

  • Add regression tests using collision-prone thread-id corpus (normalized-equivalent forms).
  • Demonstrate no key aliasing and backward-read compatibility.
  • Run checkpoint library format/lint/test gates.

Repro Evidence Packet

  • Version/commit under test: origin/main as of 2026-02-20.
  • Environment: macOS (Darwin), Python/uv per repo setup.
  • Minimal repro:
    1. Persist checkpoints for thread IDs that would collide under normalization-only schemes.
    2. Read each checkpoint back independently.
  • Expected: independent retrieval, no overwrite/alias.
  • Actual: contract is currently implicit; needs explicit non-regression coverage.
Originally created by @davidahmann on GitHub (Feb 20, 2026). ## Problem Checkpoint identity must remain collision-safe in multi-tenant usage; if key derivation ever regresses toward normalized-thread-only behavior, different tenant thread IDs could alias. ## Why Now Tenant density is increasing and checkpoint correctness is a platform contract. We need explicit regression coverage so this guarantee cannot silently regress. ## Current Behavior Is Insufficient Current implementations rely on composite keying (`thread_id`, namespace, checkpoint id), but this safety property is not clearly enforced by dedicated collision-focused tests across checkpointers. ## Why Code Change This needs code-level contract tests and any small hardening required in key-construction paths; docs are not sufficient. ## Scope / Codepaths - `libs/checkpoint/...` - `libs/checkpoint-postgres/langgraph/checkpoint/postgres/base.py` - `libs/checkpoint-sqlite/langgraph/checkpoint/sqlite/aio.py` ## Acceptance / Validation - Add regression tests using collision-prone thread-id corpus (normalized-equivalent forms). - Demonstrate no key aliasing and backward-read compatibility. - Run checkpoint library format/lint/test gates. ## Repro Evidence Packet - Version/commit under test: `origin/main` as of 2026-02-20. - Environment: macOS (Darwin), Python/uv per repo setup. - Minimal repro: 1. Persist checkpoints for thread IDs that would collide under normalization-only schemes. 2. Read each checkpoint back independently. - Expected: independent retrieval, no overwrite/alias. - Actual: contract is currently implicit; needs explicit non-regression coverage.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agents
awaiting author revision
bug
change
chat models
checkpointer
ci
code quality
code quality
dependencies
documentation
drawing
duplicate
enhancement
good first issue
help wanted
invalid
maintainer
meta
missing information
not maintained by langchain
open-swe-auto
open-swe-max
open-swe-max-auto
pending
performance
pull-request
Mirrored from GitHub Pull Request
 question
requires design
sdk
server
stale
studio
tests
type checking
usage question
v0.5
v1.1
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langchain-ai/langgraph#1156
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?