You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PraisonAI PR #1892 was merged on 2026-06-12. It fixes two high-severity correctness bugs in features that are already documented in PraisonAIDocs. Two existing docs pages need to be updated (no new pages needed), and one page also has pre-existing merge-conflict markers that should be cleaned up while we're there.
This is a content update task — folder rules are respected (all edits land in docs/features/ and docs/cli/, no docs/concepts/ changes).
_acquire_exclusive_lock / _release_exclusive_lock now lock the entire file on Windows (lock_length = max(file_size, 1)); save() reloads-under-lock and merges concurrent messages; load() always reads disk-fresh.
Files To Update (existing — do NOT create new pages)
1. docs/features/bot-unknown-user-pairing.mdx
The page already documents the inline-button Approve / Deny flow. It does not mention that older releases had a bug where tapping Approve looked successful but never actually paired the user. Users on a pinned older version will hit this and search the docs.
In the How It Works sequence diagram description, make explicit that the value embedded in the callback's channel field is the platform type (telegram / discord / slack), not the chat ID. Today the prose is silent on this.
In Platform-specific UI accordions, the callback-data format already reads pair:{action}:{channel}:{user_id}:{code}:{sig} — add a one-line note clarifying that {channel} here is the platform identifier, since this is what PairingStore.is_paired() checks against.
Do not change the Quick Start code — the public API (unknown_user_policy="pair", owner_user_id="...") is unchanged. Bug was internal.
2. docs/features/session-persistence.mdx
Two issues on this page:
a) Pre-existing merge-conflict markers in the source. The current file on main contains live <<<<<<< HEAD / ======= / >>>>>>> origin/main markers around the "Multi-Process Safety" section, plus duplicated mermaid diagrams and an API Reference table that lists add_message twice. This is breaking the rendered page. Resolve in favour of the origin/main side (the version that describes reload-under-lock, fresh reads, and the praisonai session UnifiedSessionStore Note) and delete the duplicates. Keep exactly one of each of the three sequence diagrams.
b) Add the PR #1892 fix to the existing UnifiedSessionStore Note. The current Note says both stores "use the same cross-platform locking strategy as of PR #1837". Extend it (or add a follow-up Info) saying:
Updated in PR #1892: UnifiedSessionStore.save() now reloads under lock and merges concurrent writes (previously it overwrote with the in-process cache, dropping messages from a second process that wrote between load and save). UnifiedSessionStore.load() always reads from disk. The Windows code path now locks the entire file (max(file_size, 1) bytes via msvcrt.locking) instead of only the first byte, matching the Unix fcntl.flock semantics.
Cross-link to /docs/cli/session#cross-platform-support (already present).
3. docs/cli/session.mdx
The Cross-Platform Support section already documents msvcrt.locking on Windows and links to PR #1837. Update the same section for PR #1892:
In the Windows row of the platform table, change the description from a generic mention of msvcrt.locking() to: "Whole-file lock (max(file_size, 1) bytes) — matches Unix fcntl.flock semantics".
Add a new short subsection (or extend the Note) titled something like "Concurrent message safety" stating:
The CLI's UnifiedSessionStore is safe under two processes writing the same session file (e.g. praisonai --interactive while a TUI is open, or two praisonai shells sharing the same session).
Each save() reloads, merges new messages, deduplicates, and writes under the cross-platform lock.
No changes to Commands, Use Cases, Auto-Save Sessions, History in Context, Workflow Checkpoints, or Storage Backend Options — those are unaffected.
What NOT To Do
Do not create a new "Bot pairing channel_type fix" page or a new "UnifiedSessionStore" page. The features are already documented; only the existing pages need touch-ups.
Do not edit anything under docs/concepts/ (docs/concepts/session-management.mdx references session CLI but does not need changes — it's not the SDK truth for these stores).
Do not edit docs/js/ or docs/rust/ — these are auto-generated.
Do not modify docs.json — these are existing pages, no sidebar changes.
Do not change public Python API signatures in code examples — BotConfig, Agent(memory={"session_id": ...}), praisonai session start/list/resume all still work the same way. Bug fixes only.
Suggested Structure For The Pairing Info Callout
For the user-facing Info on bot-unknown-user-pairing.mdx, prefer a positive framing (what works now) over a defect-list, in keeping with the project style. Example:
<Info>
**Inline approvals (PR #1892)**: When the owner taps **Approve** on the Telegram / Discord / Slack DM, the requester is paired immediately on the platform type (`telegram` / `discord` / `slack`) so all of their later messages flow straight through. If you saw "approve looked successful but the next message was still blocked" on an older release, upgrade to pick up this fix.
</Info>
Suggested Mermaid Addition (optional)
If a small visual helps on session-persistence.mdx, a single sequence diagram (replacing the duplicated ones currently in the file) for two CLI processes writing the same session:
sequenceDiagram
participant CLI_A as Process A (save)
participant Disk as session-1.json
participant CLI_B as Process B (save)
CLI_A->>Disk: FileLock acquire
CLI_A->>Disk: reload, merge ["hi from A"]
CLI_A->>Disk: atomic write
CLI_A->>Disk: FileLock release
CLI_B->>Disk: FileLock acquire
CLI_B->>Disk: reload (sees "hi from A"), merge ["hi from B"]
CLI_B->>Disk: atomic write
CLI_B->>Disk: FileLock release
Note over Disk: Final file contains both messages
Loading
Use the standard color scheme from AGENTS.md §3.1 (#8B0000 for processes, #189AB4 for the file).
Summary
PraisonAI PR #1892 was merged on 2026-06-12. It fixes two high-severity correctness bugs in features that are already documented in PraisonAIDocs. Two existing docs pages need to be updated (no new pages needed), and one page also has pre-existing merge-conflict markers that should be cleaned up while we're there.
This is a content update task — folder rules are respected (all edits land in
docs/features/anddocs/cli/, nodocs/concepts/changes).Source Of Truth (SDK)
praisonai/bots/_unknown_user.pysend_approval_dm(..., channel=channel_type, ...)— was previously passing the chat ID instead of the platform type.praisonai/cli/session/unified.py_acquire_exclusive_lock/_release_exclusive_locknow lock the entire file on Windows (lock_length = max(file_size, 1));save()reloads-under-lock and merges concurrent messages;load()always reads disk-fresh.Verified against PR diff (4 files, +21 / -13):
src/praisonai/praisonai/bots/_unknown_user.py(1 line)src/praisonai/praisonai/cli/session/unified.py(12 lines — Windows full-file locking)src/praisonai/tests/integration/bots/test_pairing_owner_dm.py(assertschannel == "telegram")src/praisonai/tests/integration/bots/test_pairing_agent_e2e.py(assertschannel == "discord")Files To Update (existing — do NOT create new pages)
1.
docs/features/bot-unknown-user-pairing.mdxThe page already documents the inline-button Approve / Deny flow. It does not mention that older releases had a bug where tapping Approve looked successful but never actually paired the user. Users on a pinned older version will hit this and search the docs.
Required edits:
<Info>callout near the top (alongside the existing PR docs(cli): documentpraisonai memory listsubcommand and--limitflag (v4.6.141) #1791 Gateway Info block) noting:channel_typeinPairingStore. The approval succeeded in the UI butis_paired()returnedFalseon subsequent messages — the requester stayed blocked. Upgrade to pick up the fix."channelfield is the platform type (telegram/discord/slack), not the chat ID. Today the prose is silent on this.pair:{action}:{channel}:{user_id}:{code}:{sig}— add a one-line note clarifying that{channel}here is the platform identifier, since this is whatPairingStore.is_paired()checks against.Do not change the Quick Start code — the public API (
unknown_user_policy="pair",owner_user_id="...") is unchanged. Bug was internal.2.
docs/features/session-persistence.mdxTwo issues on this page:
a) Pre-existing merge-conflict markers in the source. The current file on
maincontains live<<<<<<< HEAD/=======/>>>>>>> origin/mainmarkers around the "Multi-Process Safety" section, plus duplicated mermaid diagrams and anAPI Referencetable that listsadd_messagetwice. This is breaking the rendered page. Resolve in favour of theorigin/mainside (the version that describes reload-under-lock, fresh reads, and thepraisonai sessionUnifiedSessionStore Note) and delete the duplicates. Keep exactly one of each of the three sequence diagrams.b) Add the PR #1892 fix to the existing
UnifiedSessionStoreNote. The current Note says both stores "use the same cross-platform locking strategy as of PR #1837". Extend it (or add a follow-up Info) saying:Cross-link to
/docs/cli/session#cross-platform-support(already present).3.
docs/cli/session.mdxThe Cross-Platform Support section already documents
msvcrt.lockingon Windows and links to PR #1837. Update the same section for PR #1892:msvcrt.locking()to: "Whole-file lock (max(file_size, 1)bytes) — matches Unixfcntl.flocksemantics".UnifiedSessionStoreis safe under two processes writing the same session file (e.g.praisonai --interactivewhile a TUI is open, or twopraisonaishells sharing the same session).save()reloads, merges new messages, deduplicates, and writes under the cross-platform lock.No changes to Commands, Use Cases, Auto-Save Sessions, History in Context, Workflow Checkpoints, or Storage Backend Options — those are unaffected.
What NOT To Do
docs/concepts/(docs/concepts/session-management.mdxreferences session CLI but does not need changes — it's not the SDK truth for these stores).docs/js/ordocs/rust/— these are auto-generated.docs.json— these are existing pages, no sidebar changes.BotConfig,Agent(memory={"session_id": ...}),praisonai session start/list/resumeall still work the same way. Bug fixes only.Suggested Structure For The Pairing Info Callout
For the user-facing Info on
bot-unknown-user-pairing.mdx, prefer a positive framing (what works now) over a defect-list, in keeping with the project style. Example:Suggested Mermaid Addition (optional)
If a small visual helps on
session-persistence.mdx, a single sequence diagram (replacing the duplicated ones currently in the file) for two CLI processes writing the same session:sequenceDiagram participant CLI_A as Process A (save) participant Disk as session-1.json participant CLI_B as Process B (save) CLI_A->>Disk: FileLock acquire CLI_A->>Disk: reload, merge ["hi from A"] CLI_A->>Disk: atomic write CLI_A->>Disk: FileLock release CLI_B->>Disk: FileLock acquire CLI_B->>Disk: reload (sees "hi from A"), merge ["hi from B"] CLI_B->>Disk: atomic write CLI_B->>Disk: FileLock release Note over Disk: Final file contains both messagesUse the standard color scheme from
AGENTS.md§3.1 (#8B0000for processes,#189AB4for the file).Acceptance Checklist (for the implementing agent)
docs/features/bot-unknown-user-pairing.mdx: Info callout about PR docs: cover named-agent subagent delegation (mode: subagent + --subagents + agent_resolver) #1892 added; sequence-diagram prose clarifieschannel= platform type; HMAC callback-format note clarifies{channel}field.docs/features/session-persistence.mdx: All<<<<<<</=======/>>>>>>>conflict markers removed; duplicate diagrams and duplicateAPI Referencerows removed;UnifiedSessionStoreNote extended with PR docs: cover named-agent subagent delegation (mode: subagent + --subagents + agent_resolver) #1892 details (reload-under-lock, dedup, Windows full-file lock).docs/cli/session.mdx: Windows row of cross-platform table updated to mention whole-file lock; concurrent-write safety paragraph added; PR docs: cover named-agent subagent delegation (mode: subagent + --subagents + agent_resolver) #1892 cross-link added next to existing PR docs: add pages for two new SDK evaluators — ContextEvaluator + HarnessEvaluator #1837 reference.AGENTS.md§3.1.docs/concepts/changes; nodocs.jsonedits.Source PR: MervinPraison/PraisonAI#1892
Related earlier PRs already cited in docs: #1709, #1724, #1745, #1781, #1791, #1837