Support multiple concurrent conversations in different sessions

[JeanMertz]

Currently, jp faces several challenges when multiple conversations are run simultaneously across different terminal sessions or tabs. This enhancement request outlines the issues and proposes solutions for robust concurrent conversation support, which is essential for more advanced agentic workflows.

Context

When working on multiple projects or issues simultaneously, users often want to run jp queries in different terminal tabs or sessions concurrently. However, the current implementation has several architectural limitations that can lead to state conflicts and data loss.

The specific issues are:

Single Query File Conflict: The current system uses a single QUERY_MESSAGE.md file in the workspace root. When multiple sessions attempt to create/modify this file simultaneously, they can interfere with each other.

State Persistence Race Conditions: The jp command loads all state from disk on startup and persists the entire state atomically on exit. When multiple processes do this concurrently, later processes can overwrite changes made by earlier ones, causing data loss.

Active Conversation Conflicts: The "active conversation" flag is changed in-memory when jp query --new runs. If multiple processes change this flag and then persist state, one process can overwrite the active conversation changes made by another process.

Alternatives

Currently, users must wait for one conversation to complete before starting another, or risk losing conversation state due to concurrent access issues. Some users work around this by using separate workspace directories, but this defeats the purpose of having a unified conversation history.

Proposed Implementation

The solution involves three main architectural changes:

1. Per-Session Query Files: Replace the single QUERY_MESSAGE.md with session-specific query files using process IDs or unique identifiers (e.g., QUERY_MESSAGE_12345.md).

2. Granular State Locking: Implement file-level locking or atomic updates for individual conversation state files rather than loading/persisting the entire workspace state as a single unit.

3. Active Conversation Isolation: Either change the default behavior to start new conversations by default, or implement proper conflict resolution when multiple processes attempt to change the active conversation simultaneously.

Tasks

• Replace global QUERY_MESSAGE.md with session-specific files using process ID or unique session identifiers
• Implement granular state persistence that only updates modified conversation data rather than the entire state
• Add file locking or atomic update mechanisms for individual conversation directories
• Implement conflict detection and resolution for concurrent active conversation changes
• Consider changing default behavior to jp query --new unless --continue is specified
• Add tests for concurrent conversation scenarios
• Update documentation to reflect new concurrent usage patterns

Resources

• https://github.com/dcdpr/jp/blob/main/crates/jp_cli/src/editor.rs#L17
• https://github.com/dcdpr/jp/blob/main/crates/jp_workspace/src/lib.rs#L159-L191
• Make conversation management more powerful #57
• Long-term memory system #102