[BUG] [v0.0.7] cortex stats --days includes sessions with missing or unparseable timestamps — date filter silently bypassed for corrupt/incomplete session files

[vasylchow]

Project

cortex

Description

In src/cortex-cli/src/stats_cmd.rs lines 364-371, the --days date filter uses a chained if let expression:
if let Ok(session_data) = parse_session_file(&path) {
if let Some(ref timestamp) = session_data.timestamp
&& let Ok(session_date) = chrono::DateTime::parse_from_rfc3339(timestamp)
&& session_date < start_date
{
continue;
}
// ... session is processed below
The continue (skip this session) only executes when ALL three conditions are true: timestamp exists, parses as valid RFC3339, AND is before start_date. If timestamp is None (missing field) or the parse fails (malformed string like "not-a-real-date"), the entire if let chain short-circuits to false, the continue is never reached, and the session is included in the aggregated stats regardless of the --days filter.
This means old, corrupt, or incomplete session files with missing/invalid timestamps will always appear in cortex stats --days 1 (or any value), inflating token counts and cost estimates.

Error Message

Debug Logs

System Information

Ubuntu 24.04

Screenshots

Steps to Reproduce

1. Create a session JSON file with a missing timestamp and nonzero token data:

cat > ~/.cortex/sessions/bad-timestamp-test.json << 'EOF'
{
  "id": "bad-timestamp-test",
  "model": "gpt-4o",
  "messages": [{"role": "user", "content": "test"}],
  "usage": {"input_tokens": 9999, "output_tokens": 9999},
  "message_count": 1
}
EOF

2. Create a second session JSON file with a malformed timestamp:

cat > ~/.cortex/sessions/bad-timestamp-test2.json << 'EOF'
{
  "id": "bad-timestamp-test2",
  "timestamp": "not-a-real-date",
  "model": "gpt-4o",
  "messages": [{"role": "user", "content": "test"}],
  "usage": {"input_tokens": 5555, "output_tokens": 5555},
  "message_count": 1
}
EOF

3. Run cortex stats --days 1 — observe the output includes both bad sessions
4. Clean up the test files:
   rm ~/.cortex/sessions/bad-timestamp-test.json ~/.cortex/sessions/bad-timestamp-test2.json
5. Run cortex stats --days 1 again — now shows zero.

Expected Behavior

Sessions with missing or unparseable timestamps should be excluded from --days filtered results (or at minimum, a warning should be emitted). A session that cannot be placed on a timeline should not pass a date-range filter.

Actual Behavior

Sessions with timestamp: None or unparseable timestamp strings silently bypass the --days filter and are always included in stats, inflating token counts and cost estimates for any date range. As demonstrated, two fabricated sessions with 15,554 input + 15,554 output tokens and an estimated cost of $0.19 appear in --days 1 results despite having no valid timestamp.

Additional Context

No response

[echobt]

✅ Validation Result: VALID

Reason

The issue correctly identifies a logic flaw in src/cortex-cli/src/stats_cmd.rs where the --days filter is applied.

        // Try to parse the session
        if let Ok(session_data) = parse_session_file(&path) {
            // Check if session is within date range
            if let Some(ref timestamp) = session_data.timestamp
                && let Ok(session_date) = chrono::DateTime::parse_from_rfc3339(timestamp)
                && session_date < start_date
            {
                continue;
            }

Because the continue statement is only reached if the timestamp exists, is valid, AND is older than start_date, any session with a missing or unparseable timestamp will fail the if let condition, skip the continue, and be included in the aggregated statistics. This means corrupt or incomplete session files will always bypass the date filter and inflate the token counts and cost estimates.

The screenshot is authentic and demonstrates the bug by showing that creating a session with a missing timestamp and another with an invalid timestamp causes them to be included in cortex stats --days 1, and removing them causes the stats to drop to zero.

No duplicates were found. The bug is verified in the codebase.

Verification Checklist

• ✅ Screenshot/video provided
• ✅ Images accessible
• ✅ Shows CLI/TUI interface
• ✅ Screenshot shows a visible bug
• ✅ Screenshot matches the issue description
• ✅ Screenshot appears authentic
• ✅ Code matches description
• ✅ No duplicates found