Skip to content

Bound file IO concurrency for attachments and team memory sync #1947

Description

@GautamBytes

Summary

Bound filesystem work in attachment collection and team memory sync so OpenClaude does not kick off too many stat / readFile / writeFile calls at once.

Problem

Some code paths currently fan out file IO with broad Promise.all style work.

In large repos, big changed-file sets, or large team-memory dirs, this can create avoidable IO pressure, slower prompt setup, and less predictable abort/timeout behavior.

Proposed Direction

Add a small bounded async helper and use it in the hot file IO paths:

  • at-mentioned file processing
  • changed file attachment reads
  • team-memory local reads
  • team-memory remote writes

Keep the existing behavior intact:

  • preserve input order
  • keep permission checks
  • keep secret scanning
  • keep file-size limits
  • keep path validation
  • keep abort handling

Start with a simple fixed cap, like 8, plus focused tests for concurrency, aborts, and deterministic team-memory truncation.

Alternatives Considered

Keep the current broad fan-out behavior, but that still risks scheduling too much file IO at once.

Making the cap configurable could be useful later, but a small internal default is enough for the first pass.

Additional Context

Similar prior art exists in memory scanning work, where bounded traversal/read behavior improved large-directory handling. This applies the same idea to attachment and team-memory paths.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions