[Bug] Session state JSON corruption causes persistent 422 errors (Extra data)

[zealonexp]

Bug Description

Session state JSON files become corrupted due to concurrent write race conditions, causing JSONDecodeError: Extra data on every subsequent request to the affected session. Once corrupted, the session is permanently broken (all messages return 422) until the file is manually repaired.

Reproduction

Running CoPaw with QQ channel over several hours. The session file grows to ~400KB+. Concurrent save_session_state / update_session_state calls interleave their writes, producing a file with a valid JSON object followed by garbage fragments.

Error log:

ERROR copaw/app/runner/runner.py:564 | Error in query handler: [422] AGENT_UNKNOWN_ERROR: 
Unknown agent error: JSONDecodeError: Extra data: line 1 column 321545 (char 321544)

Corrupted file analysis:

File size: 321561 chars
First JSON object ends at char 321544
Remaining chars: 17
Remaining content: '==============\"}}'

Root Cause

SafeJSONSession has three file operations (save_session_state, update_session_state, get_session_state_dict) accessing the same session file without any locking. save_session_state uses synchronous open("w") while load_session_state/update_session_state use aiofiles. When two coroutines execute open("w") nearly simultaneously, OS-level writes interleave, producing concatenated JSON fragments.

Proposed Fix

Add JSONDecodeError catch with raw_decode fallback at all three json.loads call sites in SafeJSONSession. When corruption is detected, the first valid JSON object is extracted and a warning is logged, instead of crashing.

Environment

• CoPaw version: 1.0.2
• Channel: QQ
• Python: 3.13
• OS: Ubuntu 25.10

[github-actions]

Welcome to CoPaw! 🐾

Hi @zealonexp, thank you for your first issue!

We'll review your issue soon. Thank you for supporting CoPaw!

---

Tip

⭐ If you find CoPaw useful, please give us a Star!

Staying ahead

Star CoPaw on GitHub and be instantly notified of new releases.

Your star helps more developers discover this project! 🐾

[zealonexp]

🔁 Bug still present in v1.1.1-beta.1

I just verified that this concurrency bug still exists in the latest release v1.1.1-beta.1 (released 2026-04-13).

What I checked

Cloned v1.1.1-beta.1 and inspected src/qwenpaw/app/runner/session.py:

• save_session_state (line 85): uses bare open("w") — no lock, no atomic write
• update_session_state (line 181): same bare open("w") — no lock, no atomic write
• get_session_state_dict (line 218): reads without any coordination with concurrent writers

All three methods operate on the same session JSON file with zero concurrency protection. When two async coroutines call save_session_state and update_session_state concurrently on the same session, their open("w") calls interleave at the OS level, producing a file like:

{"conversation": [...]}{"

which causes json.JSONDecodeError: Extra data on every subsequent read.

Reproduction scenario

This is easily triggered in production when:

1. A user sends a message (triggers save_session_state)
2. Simultaneously a cron/background task calls update_session_state on the same session
3. The writes interleave → file corrupted → all future requests to that session fail

Impact

• Severity: P0 — once corrupted, the session is permanently broken
• Blast radius: every request to the affected session returns 500
• Recovery: requires manual file deletion or repair

Recommended fix

At minimum, add file-level locking (e.g., fcntl.flock on Linux / msvcrt.locking on Windows) around all read-modify-write cycles. For a more robust approach, consider atomic writes (write to temp file + os.rename).

Happy to help test any fix — I have been running with the patch from PR #3278 in production for a few days now with zero corruption incidents.