Fix: Phase 2 WAL dump bugs and add cache viewer

[akeenkarkare]

Summary

• Fixed cache_manager method name bug in admin endpoint (get_stats() → get_cache_stats())
• Added cache viewer tab to log viewer HTML for debugging
• Added scrolling to cache viewer containers

Changes

• routes/admin.py: Fixed method call to use correct get_cache_stats() method name
• static/log_viewer.html: Added cache status viewer tab with stats display and scrollable containers
• Removed CACHE_FIX_PLAN.md (no longer needed)

Test plan

• Verify cache viewer loads without errors
• Check cache statistics display correctly
• Test WAL status display
• Verify dirty entries tracking with scrolling
• Test manual cache dump button
• Confirm containers scroll properly with many entries

🤖 Generated with Claude Code

[coderabbitai]

Warning

Rate limit exceeded

@akeenkarkare has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 16 minutes and 11 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between f7996c2 and d5c0851.

📒 Files selected for processing (1)

• scripts/fastapi/static/log_viewer.html (1 hunks)

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/phase2-wal-dump-fix

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[akeenkarkare]

Critical Fix: DynamoDB Reserved Keyword Handling

The Problem

The cache dump was failing at WAL sequence #3 with:

ValidationException: Invalid UpdateExpression: Attribute name is a reserved keyword; reserved keyword: users

This caused 92,000+ WAL entries to queue up (19.7 MB file) and only 2 entries to sync successfully. No data was persisting to DynamoDB, effectively breaking the entire application.

Root Cause

The UPDATE and INCREMENT operations in cache_dumper.py were building UpdateExpressions like:

f"{field} = :{field}"  # ❌ Fails if field is reserved keyword like 'users'

DynamoDB has 573 reserved keywords including: users, status, name, data, count, etc.

The Fix

Both UPDATE and INCREMENT operations now use ExpressionAttributeNames to escape field names:

f"#{field} = :{field}"  # ✅ Safe - #{field} mapped via ExpressionAttributeNames

Changes in commit 294820f:

• Added expr_attr_names = {} dictionary to both operations
• Changed UpdateExpression to use #{field} placeholders
• Map #{field} to actual field name: expr_attr_names[f"#{field}"] = field
• Pass ExpressionAttributeNames=expr_attr_names to ddb.update_item()

Testing Required

Once deployed to production server:

1. Manually trigger cache dump: POST /admin/cache/dump?api_key=...
2. Verify all 92,000+ WAL entries sync successfully
3. Check cache status to confirm checkpoint advances past sequence pr test for coderabbit #3
4. Monitor automatic background dumps (every 10 minutes)

This fix should unblock the WAL queue and restore data persistence to DynamoDB.