Skip to content

Conversation

@xiaocang
Copy link
Contributor

@xiaocang xiaocang commented Jul 13, 2025

Description

Implement local file-based streaming intermediary for network resilience

  • Local File Intermediary System
  • Network Recovery with File Resume
    • Enhanced Streaming Architecture
  • Add resume/status API endpoints for file-based streaming recovery

This architecture allows streaming to continue on server writing to local files
while client can disconnect/reconnect and resume reading from the same files,
providing true network resilience through file-based intermediary approach.

Type of Change

Please add the appropriate label(s) to this PR and check the relevant box(es):

  • 🐛 bug - Bug fix (non-breaking change which fixes an issue)
  • feature - New feature (non-breaking change which adds functionality)
  • 💥 breaking - Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • 📚 documentation - Documentation update
  • performance - Performance improvement
  • 🔨 refactor - Code refactoring
  • 🧪 test - Adding or updating tests
  • 🔧 chore - Maintenance, dependencies, tooling

Changes Made

  • List key changes
  • Include any breaking changes
  • Mention new dependencies or configuration changes

Testing

  • Tests pass locally (make test)
  • Code is formatted (make format)
  • Code is linted (make lint)
  • Type checking passes (make typecheck)
  • All quality checks pass (make check)
  • Manual testing performed (describe what was tested)

Checklist

  • My code follows the project's style guidelines
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added/updated tests for my changes
  • All tests pass

Screenshots (if applicable)

Add screenshots to help explain your changes.

Additional Notes

Any additional information, dependencies, or context needed for reviewers.

xiaocang added 5 commits July 13, 2025 16:44
- Added functionality to load additional messages from streaming files based on session ID.
- Merged non-duplicate streaming messages with existing conversation history.
- Updated conversation metadata, including message count and end time.
- Introduced a new utility function `getStreamingMessages` to retrieve messages from streaming files.

This enhancement improves the conversation loading process by ensuring that the latest messages are included, providing a more comprehensive chat history.
@xiaocang xiaocang changed the title feature: Add local file intermediary for network-resilient streaming Draft: feature: Add local file intermediary for network-resilient streaming Jul 13, 2025
@sugyan
Copy link
Owner

sugyan commented Jul 13, 2025

Hi @xiaocang, thanks for working on this network resilience feature! I have a few questions about the use cases and scope:

Could you help me understand the specific scenarios where this file-based streaming intermediary would be needed? If the network is unstable enough to require file-based resumption for the web UI streaming, wouldn't the underlying claude CLI command itself also struggle with network connectivity issues?

This appears to be quite a large architectural change (1020+ lines) that touches many core components. I'm wondering if the expected use cases justify such an extensive modification.

Could you share more details about the real-world scenarios you're trying to solve? Thanks!

@xiaocang
Copy link
Contributor Author

Could you help me understand the specific scenarios where this file-based streaming intermediary would be needed? If the network is unstable enough to require file-based resumption for the web UI streaming, wouldn't the underlying claude CLI command itself also struggle with network connectivity issues?

I connect to my computer's network on my phone and write code using the web version of claude code, then as soon as my phone locks up or my mobile network switches, the whole session is interrupted and I have to retype the commands again

This appears to be quite a large architectural change (1020+ lines) that touches many core components. I'm wondering if the expected use cases justify such an extensive modification.

I'm still developing on this branch and I'll try to minimize some more irrelevant changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants