Repository navigation
feat: support rcrewai 0.9 (concurrency) - #28
Merged
Merged
Conversation
rcrewai 0.9.0's theme is concurrency: a turn's tool calls, consensus proposals and scoring, and embeddings for providers without a batch endpoint now fan out across bounded thread pools. It is additive with no API changes, and the 0.8.1 suite passed against it untouched. The part that matters to this engine is that tool events are now emitted from worker threads. The observation collector attributes spans using the run span id that 0.8 added, so concurrency is exactly the case that could break it. The gem captures Events.current_parent and re-establishes it inside each worker (Events.with_parent is thread-local by design), and a probe against the real gem confirms it: two 150ms tools in one turn finish in 155ms rather than ~300ms, and every resulting event carries the correct parent_id with none nil. Added collector specs for that shape - interleaved starts and results matched by call_id rather than arrival order, a failing tool not affecting its sibling, and delivery from eight threads at once. SpanStack already guards its call-id map with a mutex, so no engine change was needed for correctness. Exposed the one new knob users cannot otherwise reach, since the engine builds agents from DB records: rcrewai_agents.parallel_tools forwards parallel_tools: to RCrewAI::Agent, for an agent whose tools are not safe to run in parallel or that must not fan out against a rate-limited API. Nullable and only forwarded when explicitly set, so existing agents keep the gem's default. 268 examples, 0 failures. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0123Ahvp1Cd6DoAgfr5bsYm2
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tracks rcrewai 0.9.0, whose theme is concurrency: a turn's tool calls, consensus proposals/scoring, and embeddings now fan out across bounded thread pools. Additive, no API changes — the 0.8.1 suite passed against it untouched.
Why this needed real verification
0.9 emits tool events from worker threads. The observation collector attributes spans using the run span id that 0.8 introduced, so concurrency is precisely the case that could break it.
The gem handles it correctly: it captures
Events.current_parentand re-establishes it inside each worker (Events.with_parentis thread-local by design). I confirmed this against the real gem rather than trusting the changelog — two 150ms tools in one turn finish in 155ms, not ~300ms, and every resulting event carries the correctparent_id, none nil.Added collector specs for that shape:
call_idrather than arrival orderSpanStackalready guards its call-id map with a mutex, so no engine change was needed for correctness — but it's now covered by tests instead of assumed.Added
rcrewai_agents.parallel_toolsforwardsparallel_tools:toRCrewAI::Agent. This is the one new knob users can't otherwise reach, since the engine builds agents from DB records. Use it for an agent whose tools aren't safe to run in parallel, or that must not fan out against a rate-limited API:Nullable and only forwarded when explicitly set, so existing agents keep the gem's default (concurrency on).
Verification
268 examples, 0 failures, random order.
Upgrading
One nullable column. Nothing changes until you set it.
🤖 Generated with Claude Code
https://claude.ai/code/session_0123Ahvp1Cd6DoAgfr5bsYm2