fix(terminal): pop all entries from a single execution when the limit is exceeded

[waleedlatif1]

Summary

• pop all entries from a single execution when the limit is exceeded

Type of Change

• New Feature

Testing

Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Review	Updated (UTC)
docs	Skipped		Jan 14, 2026 7:00pm

[greptile-apps]

Greptile Summary

Changed the terminal console store's trimming logic to maintain execution atomicity when the entry limit is exceeded. Previously, the store would trim entries per workflow by simply counting up to MAX_ENTRIES_PER_WORKFLOW (500), which could split logs from a single execution across the trim boundary. The new implementation groups entries by workflow, then by execution, and removes entire executions atomically when the limit is exceeded. Also increased the limit from 500 to 1000 entries per workflow.

Key changes:

• Groups console entries by workflowId and then by executionId (falling back to entry id)
• Builds an execution order based on entry insertion order
• Counts entries per execution
• Keeps the newest complete executions that fit within the limit
• Removes all entries from executions that don't fit (atomic removal)
• Increased MAX_ENTRIES_PER_WORKFLOW from 500 to 1000

Confidence Score: 4/5

• This PR is safe to merge with minimal risk - the logic is sound and improves data consistency
• The execution-aware trimming logic correctly maintains atomicity of execution logs. The implementation properly handles fallback from executionId to id, groups entries correctly, and filters atomically. Increased limit provides more history. Minor concern: complexity increased significantly (simple counter → multi-map grouping), but the benefit of atomic execution removal justifies it
• No files require special attention

Important Files Changed

Filename	Overview
apps/sim/stores/terminal/console/store.ts	Changed trimming logic from simple per-workflow count limit to execution-aware batching; increased MAX_ENTRIES_PER_WORKFLOW from 500 to 1000

Sequence Diagram

sequenceDiagram
    participant User
    participant addConsole
    participant State
    participant Trimming Logic
    participant Storage

    User->>addConsole: Add new console entry
    addConsole->>addConsole: Redact API keys
    addConsole->>addConsole: Create entry with UUID & timestamp
    addConsole->>State: Prepend to entries array
    
    State->>Trimming Logic: Check if trimming needed
    Trimming Logic->>Trimming Logic: Group entries by workflowId
    
    loop For each workflow group
        Trimming Logic->>Trimming Logic: Count entries per workflow
        alt Entries > MAX_ENTRIES_PER_WORKFLOW
            Trimming Logic->>Trimming Logic: Build execution order list
            Trimming Logic->>Trimming Logic: Count entries per execution
            Trimming Logic->>Trimming Logic: Keep newest executions (atomic)
            Trimming Logic->>Trimming Logic: Mark old executions for removal
        end
    end
    
    Trimming Logic->>State: Filter out marked executions
    State->>Storage: Persist trimmed entries
    addConsole->>User: Return new entry

Loading