⚠️ Critical: Timestamp Corruption in v8.25.0-v8.27.0 Hybrid Backend - Recovery Guide

[doobidoo]

Summary

A critical bug in the hybrid backend's drift detection caused timestamp corruption during Cloudflare synchronization. All created_at timestamps were overwritten with the sync time instead of preserving original creation dates.

Affected Versions: v8.25.0, v8.26.0, v8.27.0
Fixed In: v8.27.1
Impact: Up to 86% of memories may show incorrect creation dates

---

How to Check If You're Affected

Run this diagnostic query on your SQLite database:

import sqlite3
import os

db_path = os.path.expanduser("~/Library/Application Support/mcp-memory/sqlite_vec.db")
conn = sqlite3.connect(db_path)
cursor = conn.cursor()

# Check date distribution
cursor.execute("""
    SELECT
        substr(created_at_iso, 1, 10) as date,
        COUNT(*) as count
    FROM memories
    GROUP BY date
    ORDER BY count DESC
    LIMIT 5
""")

print("Top 5 dates by memory count:")
for row in cursor.fetchall():
    print(f"  {row[0]}: {row[1]} memories")

cursor.execute("SELECT COUNT(*) FROM memories")
total = cursor.fetchone()[0]

# Check for corruption (single date with >50% of memories)
cursor.execute("""
    SELECT COUNT(*) FROM memories
    WHERE created_at_iso LIKE '2025-11-16%'
       OR created_at_iso LIKE '2025-11-17%'
       OR created_at_iso LIKE '2025-11-18%'
""")
nov_count = cursor.fetchone()[0]

print(f"\nTotal memories: {total}")
print(f"Nov 16-18 dates: {nov_count} ({nov_count/total*100:.1f}%)")

if nov_count / total > 0.20:
    print("\n⚠️  WARNING: Possible timestamp corruption detected!")
    print("   Expected: <10% on any single date range")
else:
    print("\n✅ Timestamps appear normal")

conn.close()

Signs of Corruption:

• Single date contains >50% of all memories
• Date distribution shows spike on Nov 16-18, 2025 (or your sync date)
• Memories you know were created months ago show recent dates

---

Recovery Options

Option A: Restore from Dashboard Export (Recommended)

If you have a JSON export from before the corruption occurred:

1. Export from clean source (if available):

   • Dashboard → Export → Download JSON
   • Or use export from another machine that wasn't affected

2. Run recovery script:

# Preview first (dry run)
python scripts/maintenance/restore_from_json_export.py \
  --db-path "~/Library/Application Support/mcp-memory/sqlite_vec.db" \
  --mapping-file clean_export.json \
  --dry-run

# Then apply
python scripts/maintenance/restore_from_json_export.py \
  --db-path "~/Library/Application Support/mcp-memory/sqlite_vec.db" \
  --mapping-file clean_export.json

Option B: Restore from Cloudflare

If your Cloudflare backend has correct timestamps:

python scripts/maintenance/recover_timestamps_from_cloudflare.py --dry-run
python scripts/maintenance/recover_timestamps_from_cloudflare.py

---

Prevention

1. Update to v8.27.1 immediately:

git pull origin main
# Verify version
python -c "import mcp_memory_service; print(mcp_memory_service.__version__)"

2. Restart MCP servers to load the fix:

/mcp  # In Claude Code

3. Future syncs will now preserve original timestamps correctly.

---

Technical Details

Root Cause:
The hybrid backend's drift detection (hybrid.py lines 924-936) updated metadata without including created_at fields, causing them to be reset to current time during update_memory_metadata().

Fix in v8.27.1:

• hybrid.py: Drift detection now includes created_at and created_at_iso in updates
• sqlite_vec.py: update_memory_metadata() respects preserve_timestamps flag
• cloudflare.py: Consistent timestamp handling

Related:

• PR feat(storage): add AND/OR tag filtering for Cloudflare backend #228: Timestamp preservation hotfix
• Scripts: scripts/maintenance/restore_from_json_export.py

---

Need Help?

If you're affected and need assistance with recovery:

1. Open an issue with your diagnostic output
2. Include your MCP Memory Service version
3. Describe your storage backend configuration (hybrid/cloudflare/sqlite-vec)

We apologize for any inconvenience caused by this bug.