Bus storage is unstorage: delete bespoke storage code, consumers pick the driver - #18
Conversation
The bus no longer owns any storage logic. AgentBusSettings.storage takes any unstorage instance, and the consumer picks the driver — memory (the default), fs, redis, http, or anything else in the driver ecosystem. Entries live under the storage's entry:* keys. JsonlBusStore, BusFileSystem, the AgentBusStore seam, and the memfs dependency are all deleted. createHarnessLoop's bus option becomes a storage factory, defaulting to the fs driver under the run's output directory. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NG6fSKqgt8nD7JnEY9q245
|
Warning Review limit reached
Next review available in: 21 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (10)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Summary
Replaces the harness's homegrown storage layer with unstorage. The bus now owns zero storage logic: it takes any unstorage instance, and the consumer picks the driver — memory, fs, redis, http, cloud KV, or anything else in the driver ecosystem.
Changes
Harness package
AgentBusSettings.storageaccepts any unstorageStorage; unset, the bus uses unstorage's default in-memory driver. Entries live under the storage'sentry:*keys, sorted by sequence on load, still parsed at the boundary with the zod entry schema so malformed values never enter the log. A bus expects sole write access to itsentry:*keys; shared storages should be mounted or prefixed.JsonlBusStore,BusFileSystem, theAgentBusStoreseam, all JSONL serialization/recovery code, and thememfsdependency. unstorage is the storage abstraction — nothing bespoke remains.Root package
HarnessLoopOptions.bus/actionLogFilebecome onestoragefactory:(input: TrainingLoopInput) => Storage. Unset, a run's entries land on the local filesystem via the fs driver under<outputDir>/harness-actions(defaultActionLogDir).judgeandcontextProviderstay injectable as before.Docs
createStorage({ driver: fsDriver(...) }).Testing
npm run checkpasses (typecheck for all packages, 81 tests across 15 files, package build), including a driver-swap test (memory driver with an out-of-band writer, sequence resumption) and an fs-driver persistence test across bus instances.🤖 Generated with Claude Code
https://claude.ai/code/session_01NG6fSKqgt8nD7JnEY9q245
Generated by Claude Code