757 Commits

Author	SHA1	Message	Date
João Moura	9e9a8577be	feat(events): report project creation with the id minted for it (#7074) ... * feat(telemetry): report project creation with the id minted for it Acquisition was only observable from a project's first run. That misses every project created and never run, and dates the rest to the wrong day. All three scaffolding paths already mint a project_id into the new pyproject.toml. None of them reported it, and two of them - create_crew and create_json_crew, which is the default `crewai create crew` path - emitted no telemetry at all. `Project Created` carries the kind (crew, json_crew, flow) and the id that was just minted, and is emitted after the mint so it can carry it. The attribute is `created_project_id`, not `project_id`, because those are two different things. CommonAttributesSpanProcessor stamps `project_id` on every span from get_project_id(), which reads the current working directory and is cached for the life of the process - during `crewai create` that describes the directory the command was run from, not the project being created. Reusing the name would have given one column two meanings depending on span type. Nothing is emitted for `create_crew(parent_folder=...)`: that adds a crew to a project which already exists, mints no id, and is not an acquisition. The existing `Flow Creation` span is left exactly as it is. Note for whoever reads it: it is emitted from two places with two different meanings - CLI scaffolding (create_flow.py) and runtime flow construction (event_listener.py on FlowCreatedEvent) - so it cannot separate acquisition from usage. Not changed here because it is a live series and renaming it would break continuity. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * test(telemetry): stop the creation-span tests exporting to the real collector The recorded_spans fixture has to enable telemetry for its assertions to mean anything - a disabled Telemetry never builds self.provider, so every assertion would pass vacuously against a non-recording span. But enabling it is exactly what makes __init__ wire a BatchSpanProcessor around the real SafeOTLPSpanExporter, pointed at the production collector. Measured, with a spy on both SafeOTLPSpanExporter classes reporting at interpreter exit: before this change the file made 3 real export calls, handed 3 synthetic Project Created spans with invented created_project_id values to the production exporter, and completed 3 connects to the collector. After: 0, 0, 0. Sampling at pytest_sessionfinish reports 0 either way and is how this was missed - BatchSpanProcessor flushes on a background timer, and with no provider.shutdown() the flush lands in the atexit handler, which runs after sessionfinish. --block-network does not prevent it: it is function-scoped and only swaps socket.connect, which a background batch thread outlives. Follows telemetry_with_exporter in tests/telemetry/test_tracer_isolation.py: _NullExporter swapped in before construction, _register_shutdown_handlers suppressed so no atexit hook is left behind, and provider.shutdown() in finally. Patch target is crewai_core because that is where this Telemetry comes from. Also disambiguates the docs rows: the minted ID belongs to the new project, not to the directory the command ran in, and the two can differ. Reworded in all four languages rather than renaming the token to created_project_id - this table documents data, never span-attribute keys (kind and crewai_version on the same row are unnamed), and `project_id` is already the page's name for the pyproject.toml key. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * docs(ar): use tanwin fath on the letter, not on the alif مشروعًا / جديدًا rather than مشروعاً / جديداً, in the row added by this PR. Both forms appear in docs/edge/ar (3 each), so this is not a house convention being broken either way; the corrected form is the more standard one and the text is mine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * docs: stop the creation row implying the span's project_id holds the minted value CodeRabbit re-raised this as Major after I rejected the first version, and it was right to. My rejection argued the page never names wire keys, so introducing created_project_id would be its only one. That part still holds -- grep finds no attribute key anywhere in the four files. But it was the wrong conclusion: the row still used the token `project_id` for a value the span does NOT carry under that key, while the same span's real project_id holds the cwd-derived value. The row also already exposes literal wire values (`crew`, `json_crew`, `flow` are the actual kind values), so "this page has no wire detail" was overstated. Dropping the token resolves the ambiguity without adding the page's only key name: the row now says "the project ID minted for that new project", and names `project_id` only to say the minted value is recorded separately from it. All four languages. No docs/v*/ touched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * docs: use an em dash in the creation row, matching the rest of the page The two ASCII `--` occurrences in these files were both mine, introduced by this PR: the page otherwise uses em dashes throughout (en 4, ar 4, ko 2, pt-BR 4). CodeRabbit flagged pt-BR; the same slip was in en, so both are fixed. Now zero ASCII `--` across all four language files. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-08-23 15:59:56 -03:00
João Moura	f4731f5025	feat(events): record whether a run had inputs, without recording the inputs (#7072) ... * feat(telemetry): record whether a run had inputs, without recording the inputs The `crew_inputs` payload is gated behind `share_crew` and stays that way, so the only way to tell a parameterised run from an unparameterised one was to read a gated key: it is present on roughly 0.02% of spans, all of them opt-in sharers. That is a measurement of people who opted into sharing, not of users. `crew_inputs_present` carries just the answer -- "true"/"false" -- on the already-ungated `Crew Created` span. The payload stays inside the `share_crew` branch, so nothing new about the contents of anyone's inputs is collected. A string, for the reason `crew_memory` is a string, and the encoding matters more here because the majority case is the empty one. Measured over a single day (312,424,709 spans): `vInt64='0'` occurs 0 times and `vBool='false'` occurs 0 times, while `vStr='0'` does occur. proto3 omits the zero value for ints as well as bools, so an integer key count would have silently dropped every unparameterised run -- and among sharers, 54.46% of runs pass `{}`. `{}` and `None` are both "false": an empty dict parameterises nothing, so truthiness is the question being asked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * test(telemetry): assert input keys are absent too, not only input values The gating test checked only the input value. A regression that emitted the input keys - json.dumps(sorted(inputs)) or similar - would have passed it, and key names are user data as much as values are. Verified by injecting exactly that regression: the new assertion fails on it and passes once reverted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-21 16:10:02 +05:30
João Moura	8e6c23430f	fix(flow): emit the flow lifecycle on a suppressed resume (#7071) ... * fix(flow): a resumed flow must emit flow_started, not only flow_finished _resume_async_body gated FlowStartedEvent behind suppress_flow_events while the matching FlowFinishedEvent a few hundred lines below stayed ungated. A suppressed resume therefore emitted an unpaired finish: a flow that reported finishing without ever having started. That is worse than a missing row - it breaks every started/finished pairing and any duration or funnel built on it, and it removed the resumed leg from telemetry entirely. suppress_flow_events is also the wrong gate for emission. It asks for console quiet: _flow_origin in events/event_listener.py says so explicitly and notes it "can legitimately be set on a caller's own flow", and the listener already honours it at each point where it prints. So a user who set it on their own flow for quiet output silently lost their resumed runs from telemetry. The emit is now unconditional, matching both the kickoff path - which never gated it - and the FlowFinishedEvent it pairs with. The method-execution gates in this function are left alone: _execute_method gates the same events on the same flag, so those are symmetric and intended. Internal flows that set this flag (agent_executor, the memory recall/encoding flows) will now emit a started event when resumed. That is the point, and the is_crewai_internal marker already keeps them out of user-facing flow metrics - a distinction _flow_origin draws precisely because this flag cannot carry it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * fix(flow): emit the whole lifecycle on a suppressed resume, not just the start The first commit on this branch ungated FlowStartedEvent on the resume path while FlowFinishedEvent stayed gated, which left a suppressed resume emitting a start with no terminal event. CodeRabbit and cursor both caught it. The premise that commit was written against was wrong: origin/main gated the started event and the finished event, so it emitted neither and was symmetric. It was the detection that was broken, not the code -- a fixed-line lookback for the enclosing condition missed the multi-line `if (not self.suppress_flow_events and not self._should_defer_trace_finalization()):` guarding the finish. The defect is therefore not an unpaired event on main but a silent one: a resumed run with suppress_flow_events set emits no lifecycle events at all, so it never reaches a listener or the trace exporter and the run is invisible downstream. kickoff_async emits them either way and lets listeners filter, and suppress_flow_events asks for console quiet rather than for telemetry to be dropped, so resume now matches kickoff. _should_defer_trace_finalization() still withholds the finish, which is a real reason: finalize_session_traces() emits it later instead. respect_suppression is deleted rather than left defaulting to False -- the resume call site was its only caller, so nothing passes True any more. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-21 15:51:20 +05:30
João Moura	6e714d6cad	feat(flow): accept crew-style LLM config in a conversational declaration (#7062) ... * feat(flow): accept crew-style LLM config in a conversational declaration `conversational.llm` / `intent_llm` / `answer_from_history_llm` and `router.llm` only accepted a model-id string, so a declaration could not set `max_tokens`, `temperature` or anything else a declarative crew's agent can. `_coerce_llm` now delegates to `crewai.utilities.llm_utils.create_llm` -- the same helper the crew/agent declaration layer resolves through -- so the shapes match: a model-id string, a config mapping, an `LLMDefinition`, or a live `LLM`/`BaseLLM` passed straight through. It keeps one thing `create_llm` does not: `create_llm(1234)` takes the int as a model name and returns an LLM that only fails later with a provider error. A declaration is hand-written, so a non-string, non-mapping value raises now instead. A mapping missing `model` keeps `create_llm`'s own message. The contract fields stay permissively typed and gain descriptions naming the accepted shapes. Tightening them to `str | LLMDefinition` would break the DSL projection: a live custom `BaseLLM` whose config dump lacks a `model` key degrades to a `{"ref": ...}` mapping, which such a type would reject -- turning `flow_definition()` on an existing Python flow into a validation error. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(flow): resolve declared LLM mappings for intent classification `intent_llm` and `answer_from_history_llm` were documented as taking the same shapes as `llm`, but both route through `_collapse_to_outcome`, whose own coercion accepts only `str | BaseLLM`. A declared config mapping reached it unchanged and raised "Invalid llm type: <class 'dict'>" mid-turn -- so the documentation promised something that failed. Also fixes the field descriptions. The previous commit's `llm` description landed on `FlowConversationalRouterDefinition.llm` rather than `FlowConversationalDefinition.llm`, because both fields are literally `llm: Any = None` and the first match won. All four now describe their own field and name every accepted shape, including `LLMDefinition` and a live instance. Test changes: adds an `LLMDefinition` resolution case, and the declared-mapping turn test now patches `create_llm` to prove the mapping reaches it instead of swapping the config out beforehand, which proved nothing. Found by Cursor and CodeRabbit on #7062. * docs(flows): name the full router LLM precedence; pin the coercion path The conversational llm description skipped intent_llm in the router fallback order (router.llm, then intent_llm, then llm), and the intent_llm test replaced the declared mapping with a scripted LLM before the turn, so it never exercised the coercion. Patch create_llm instead: removing the coercion now fails the test with "Invalid llm type: <class 'dict'>". Found by CodeRabbit on #7062. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-21 14:47:37 +05:30
João Moura	4718b190d1	fix(cli): open the conversational TUI for a declarative chat flow (#7060) ... * fix(cli): open the conversational TUI for a declarative chat flow `crewai run` refused a declarative conversational flow and told the user to drive it from Python. That was wrong: the conversational TUI already exists and already does this job. `CrewRunApp(conversational=True)` renders a chat pane and drives `handle_turn` per message (crew_run_tui.py:833-935), and `kickoff_flow._run_conversational_flow_tui` launches it for a Python conversational Flow. A declaration-built flow satisfies everything that TUI needs -- `handle_turn`, a settable `defer_trace_finalization`, and `finalize_session_traces()` -- so it now routes there instead of exiting. A chat loop still needs a terminal. A headless run (`is_interactive()` false, which folds in CREWAI_DMN) says what it would have needed rather than kicking off a single turn and presenting that as the whole conversation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(cli): do not send a human-feedback chat flow to the Textual TUI A declaration can carry both a `conversational:` block and a method with `human_feedback:` -- verified, both predicates return True on the same flow. Routing it to the chat TUI hangs: the runtime collects feedback with a blocking `input()` (flow/runtime/__init__.py:3719) that Textual cannot service, so the prompt is never shown. The STEPS TUI already declines these for exactly this reason. Such a flow now falls back to the terminal REPL, which can prompt. Also updates the guide in en/ar/ko/pt-BR: it still said `crewai run` has no chat loop and exits, which is now the opposite of what the CLI does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(cli): reject --inputs on a conversational flow instead of dropping it The conversational branch returns before `_resolve_flow_inputs`, and the TUI calls `handle_turn(message)` -- which owns the kickoff inputs, passing `{"id": session_id}` itself. So any `--inputs` value was silently discarded and the conversation ran as if it had been applied. It now errors, and says that resuming a session by id is not wired up yet rather than implying it worked. Also corrects the Arabic guide: `مُوجّه محجوز` reads as "reserved router", not the blocking prompt it describes. Both found by CodeRabbit on #7060. * fix(cli): document the conversational routing exceptions Three review follow-ups: - The Arabic guide read خدمته (masculine) against the feminine مُطالبة introduced by the last fix. - Both docstrings described a routing path that now has exceptions: a conversational declaration rejects --inputs and skips state-schema resolution, and a human-feedback one uses the terminal REPL. - The --inputs rejection test accepted SystemExit(0); it now pins code 1. Found by CodeRabbit on #7060. * fix(cli): reject --inputs on a chat flow even when it parses empty parse_inputs_json returns {} both when the option is absent and when the user passes --inputs "{}", so the falsy check started the TUI for the second case while the docs said it was unsupported. The conversational path now takes whether the option was supplied, not what it parsed to. Documents the restriction in en, ar, ko and pt-BR. Found by CodeRabbit on #7060. * test(cli): pin the headless conversational exit status pytest.raises(SystemExit) also accepts SystemExit(0), so the error path could regress to a successful exit unnoticed. Found by CodeRabbit on #7060. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-21 14:36:40 +05:30
João Moura	456c67d7c2	fix(telemetry): record crew_memory as a string, not a bool (#7064) ... This pipeline cannot carry a false boolean. Measured across 218,400,577 spans, not one carries vBool=false - proto3 omits the bool zero value, so false is never serialized and arrives as the key simply being absent. "Memory disabled" was therefore structurally unrepresentable, and presence had to stand in for the value, which is why crew_memory read 1 for 99.8% of crews against a field that defaults to False. The fix is the convention this file already documents and applies to `resumed` and `conversational`; crew_memory is the attribute those comments name as the outstanding case. It was the only remaining CrewAI-emitted boolean attribute - checked empirically: every other attribute appearing in vBool comes from third-party instrumentation. Truthiness rather than `is True`, per the decision that memory counts as enabled when set by any means: a Memory, MemoryScope or MemorySlice instance is enabled just as much as `memory=True`. None of those classes defines __bool__ or __len__, so an instance is always truthy. Tests cover all four inputs - True, False, None and an instance - and reuse the existing guard that no attribute is ever passed as a bare boolean. Verified they fail against the unpatched emitter. Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 21:59:35 +00:00
João Moura	0c2bcb510c	feat(cli): backfill project_id from every user-invoked project command (#7057) ... * feat(cli): backfill project_id from every user-invoked project command `crewai run` has always backfilled: a project declaring [tool.crewai] without a project_id gets one minted the first time it runs. No other command did, so a project driven entirely through `crewai test`, `crewai deploy` or `crewai traces enable` never acquired an id and every one of its runs stayed unattributable - which is the denominator problem, not a cosmetic gap. Adds the same call to train, replay, test, login, deploy create, deploy push, flow add-crew, enterprise configure and traces enable. Every one is an action the user explicitly invoked, which is the condition run_crew already relies on, so this is the existing principle applied evenly rather than a new policy. It is still never called from the SDK during kickoff, and get_or_create_project_id still refuses to create the [tool.crewai] table, so an unrelated directory is never rewritten. `crewai flow kickoff` is deliberately untouched: it delegates to run_crew and already inherits the backfill. A test pins that so the delegation is not accidentally duplicated. There is no `crewai evaluate` command - `crewai test` is that path. The call is the first statement in each command so a command that later fails still leaves the project with an id. The tests patch the backfill to raise, which proves the call happened and guarantees nothing after it runs, so no test touches user settings, spawns a subprocess or reaches the network. Verified they fail against the unpatched module: 9 command tests fail, the 2 guard tests still pass. Tests live under lib/crewai/tests/cli/ because that is the path the required CI job runs; nothing runs lib/cli/tests/. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * test(cli): assert the backfill at runtime instead of reading source text Addresses CodeRabbit and github-code-quality on #7057. The two guard tests grepped module source for a call string, which asserts on formatting rather than behavior: a reformat would break them and a real regression could slip past. They now invoke the commands in an isolated project and assert on observed calls. The flow-kickoff test patches the two distinct import sites separately and asserts run_crew's is called exactly once while cli's is not called at all, which is what makes 'delegates' and 'duplicates' distinguishable at runtime rather than by reading the file. Verified both catch what they claim: injecting a duplicate call into flow_run fails the delegation test, and removing run_crew's own call fails the run test. This also drops the module-level 'import crewai_cli.cli as cli_module' that mixed import styles with the existing 'from crewai_cli.cli import crewai', which is the code-quality finding - the rewrite removes the need for it entirely. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * test(cli): make the exact-once assertion observable Addresses CodeRabbit on #7057, and the finding was correct: with side_effect=_BackfillReached the mock raised on first use, so call_count == 1 was guaranteed by the mock rather than by the code. A second backfill call inside the same run_crew execution could never have been observed. Both backfill mocks now return normally and execution is stopped at the first call AFTER the backfill (configured_project_json_crew), so the recorded count is real. Verified the difference this makes: injecting a duplicate get_or_create_project_id() INSIDE run_crew now fails both tests, which the previous version could not detect at all. The flow_run duplicate case is still caught. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * test(cli): assert flow kickoff reaches the post-backfill boundary Addresses CodeRabbit on #7057, and the finding was right: the flow-kickoff test discarded the runner.invoke() result, so if the path returned or raised after one backfill call but before configured_project_json_crew, both call-count assertions would still have passed - for the wrong reason. test_run_still_backfills already asserted the boundary; this makes the pair consistent. Verified it earns its place: injecting an early return after the backfill and before the boundary now fails both tests, and previously would have failed neither. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * test(cli): pin that the backfill precedes command-specific work Addresses CodeRabbit on #7057. The finding is valid: the parametrized test proves the backfill is reached, not that nothing ran before it, so its assertion message claimed more than the test established. Fixed in two parts rather than as proposed. The message now states what the test actually proves, and a new test pins the ordering on login: , whose first action goes through a module-level name that can be patched without reaching into the command. Deliberately not parameterized across all nine commands, which is what the finding suggested: that would mean naming each command's current first action, and those change as commands evolve, so the suite would end up tracking their internals rather than this ordering property. One representative command establishes it, and placement is visible in the diff for the rest. Verified it catches the regression: swapping login's first two statements so its own work runs before the backfill fails the new test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 23:14:09 -07:00
João Moura	7c72d57b73	fix(events): always emit project_id so absent and empty stay distinct (#7056) ... * fix(telemetry): always emit project_id so absent and empty stay distinct common_span_attributes() stamped project_id onto every span only when the project declared one, and omitted the key otherwise. That makes two different situations indistinguishable downstream: a client too old to report a project id at all, and a current client whose project simply declares none. The consequence is not cosmetic. The share of clients that COULD have reported an id is the denominator of every attribution rate, and with both cases collapsed into "key absent" that denominator cannot be computed at all - it can only be inferred from a version floor, which is fragile and silently wrong for any client that backports or pins. The key is now always present and is the empty string when the project declares none. It still never invents an identity: get_project_id() remains read-only and minting stays with the CLI commands a user explicitly invoked. Two existing tests asserted the old contract and are updated rather than deleted, one of them renamed because its name described the behaviour that changed. A third test is added pinning the distinction itself. The test asserting that a foreign application's spans are never annotated is unaffected and still passes: this changes what our processor stamps, not where it is attached. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * docs(telemetry): note that a failed project_id lookup also yields empty Addresses CodeRabbit on #7056. The docstring and inline comment described the empty string only as an undeclared project, but the except branch sets project_id to None and so lands on the same empty value. Both are deliberately indistinguishable - neither yields an id - and saying so matters to anyone debugging an empty value, since an unreadable pyproject.toml looks identical to a project that simply declares nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 01:10:23 -03:00
João Moura	5ddf62ae7b	feat: bump versions to 1.15.17 (#7054)	2026-08-20 00:16:11 +00:00
João Moura	4dfd074fae	docs(flow): document declarative conversational flows (#7035) ... * test(flow): unskip the conversational end-to-end suite The `conversational_graph_broken` marker parked 21 end-to-end conversational tests with the reason "the definition-first start migration intentionally stopped scanning inherited methods, so that graph no longer registers". That is no longer true: `_iter_flow_methods` walks the MRO for `__conversational_only__` methods (dsl/_utils.py:406-420), so a `conversational = True` subclass does register `route_conversation`, `converse_turn`, `end_conversation` and `answer_from_history_turn` — which `test_flow_definition.py:391-407` already asserts. Removing the marker takes the file from 47 passed / 21 skipped to 68 passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(flow): make conversational opt-in unmistakable Opting a Flow into chat took two statements, and forgetting one failed silently. With `@ConversationConfig(...)` but no `conversational = True`: `FlowDefinition.conversational` came back `None`, the built-in graph never registered, and `handle_turn()` returned `None` without appending a message or raising — while `chat()` reported "only available on conversational flows" on a class that was literally decorated with a conversational config. Three changes: - `ConversationConfig.__call__` now also sets `conversational = True`. Every field on the config is consumed only by the conversational graph, so a decorated non-conversational Flow could only ever discard it. - `FlowConversationalDefinition.enabled` defaults to True. The block is absent on non-conversational flows, so declaring it is the opt-in; `enabled: false` remains an explicit opt-out. - `handle_turn()` raises like `chat()` and `stream_turn()` already do instead of silently returning `None`. Setting `conversational = True` by hand still works and is still the way to opt in without a config. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(flow): let a declaration drive conversational mode `FlowDefinition.conversational` was written by the DSL projection and read by nothing: every conversational gate resolved through `type(self).flow_definition()` — the class projection — instead of `self._definition`, the declaration a flow was actually built from. So `Flow.from_declaration()` on a definition with a conversational block produced a flow that reported itself non-conversational, dropped the user message, and never registered its declared routes. Resolution rules, applied consistently: - Structure (enabled, methods, route labels, builtin/internal routes) comes from `self._definition`, which is the loaded declaration for a declarative flow and the class projection otherwise. Both paths now agree. - Behavior (`conversational_config`) still prefers the class attribute, which can hold live objects — a configured LLM, a custom BaseLLM, a response_format model class — that the serializable definition degrades to a config dict or a `module:qualname` ref. Reading the definition first would silently downgrade every decorated Python flow. A declaration-built flow has no class config, so `_config_from_definition` supplies one, cached for stable identity. - A declared `state:` block is never replaced. `_create_default_extension_state` is consulted before `_create_definition_state`, so returning `ConversationState` there discarded every field the declaration asked for. It now yields to a declared state and only supplies the default when nothing else does. The class-scoped `_is_conversational` / `_conversational_definition` classmethods are gone; the existing instance-scoped `_is_conversational_enabled` is the single gate. A router `response_format` that survived serialization as a ref or schema dict is dropped with a warning rather than handed to `llm.call()`, which needs a real class. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(flow): synthesize the built-in conversational methods for declarations A declaration carrying `conversational: {}` loaded clean and then ran zero methods and returned `None`, because the four built-in graph handlers are inherited from `_ConversationalMixin` and a declaration has nothing to inherit from. Authors had to name `crewai.experimental.conversational_mixin:_Conversational Mixin.route_conversation` and three siblings by hand. `Flow._extend_definition` is a new runtime extension hook, called once `_definition` is resolved and before methods are bound. The conversational mixin overrides it to fill in `route_conversation`, `converse_turn`, `end_conversation` and `answer_from_history_turn` when they are missing, using the same code refs the DSL projection already emits so a declaration and a class projection of the same flow produce identical method definitions. Synthesis is deliberately a runtime concern, not a contract one: `FlowDefinition` stays independent of the authoring layer and of the engine, as `test_flow_definition_contract_is_dsl_agnostic` requires, and a loaded declaration still serializes back to exactly what its author wrote. Route descriptions are now carried by the contract. The DSL projects a handler docstring's first line into `FlowMethodDefinition.description`, and the router catalog reads that before falling back to the live docstring. This also fixes a real defect: for a declarative flow `getattr(type(self), handler_name, None)` is `None`, and the old code read `None.__doc__` — so the router LLM was told a route's description was "The type of the None singleton." Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(flow): let an agent or crew handler reply in a conversation (#7034) `handle_turn` promotes a handler's return value to the assistant message when the handler did not append one itself, but the check required `isinstance(result, str)`. Declarative `agent` and `crew` actions return `LiteAgentOutput` and `CrewOutput`, whose text lives on `.raw` — so the most natural declarative handler was exactly the one whose reply never reached the transcript. `_is_public_turn_result` now unwraps `.raw` before deciding, matching `_stringify_result`, which already did. The routing-artefact guards are applied to the unwrapped text, so an output echoing a route label or this turn's intent is still not promoted. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(flow): keep privately recorded agent results out of the transcript Unwrapping `.raw` in `_is_public_turn_result` made the end-of-turn fallback promote `LiteAgentOutput` / `CrewOutput` objects that the handler had already recorded via `append_agent_result` with the default private visibility. That call does not set `_assistant_reply_appended`, so the fallback republished the very object the handler asked to keep private — defeating `visible_agent_outputs`. Reproduced against `main` for contrast: no leak before the unwrap, leak after. `append_agent_result` now remembers the object it recorded for the duration of the turn, and the fallback skips anything already routed that way. The check is identity-based on purpose: a handler that records scratch work privately and then returns a user-facing summary still gets that summary promoted, which a simple "handler already handled it" flag would have broken. Found by Cursor Bugbot on #7033. * feat(flow): mark a declarative chat flow conversational on the instance A declaration enables chat through `conversational.enabled`, without the `conversational = True` class attribute. Callers outside this package capability-check that attribute -- the AG-UI serving guide states it as a requirement -- so it disagreed with `_is_conversational_enabled()` and a declarative conversational flow looked non-conversational from outside. `_extend_definition` now sets it on the instance when the definition enables chat. Instance-only on purpose: the DSL projection reads the attribute off the *class* to decide whether to emit a conversational block, so setting it there would make every later subclass look conversational. Verified on a real declarative flow: `conversational` and `stream_turn` both now satisfy the documented capability check, while `Flow.conversational` and any later subclass stay False. * refactor(flow): derive routing-artefact labels from the effective routes `_is_public_turn_result` matched a literal set of route labels, duplicating knowledge that `_effective_builtin_routes()` already owns. A declaration that adds a builtin route was not covered, so a handler echoing that label could be promoted into the transcript -- the same class of divergence already fixed for `route_turn`. Verified the derived set is byte-identical to the old literal one for a class-based flow, so this is a pure generalization: `conversation` and `route_to_flow` stay explicit because neither is a route. Also replaces a tuple-index lambda in the chat REPL test with a named `input_fn`; it relied on tuple evaluation order and on the list being mutated before its length was read. Both found by CodeRabbit on #7033. * docs(flow): document declarative conversational flows The authoring skill told LLM authors "use top-level `conversational` only when the user asks for a chat flow" while documenting none of its 19 fields — there was no ModelSpec for either conversational model, so the API reference appendix skipped them entirely. - Adds both conversational models to the skill reference, with field descriptions, and registers them under the existing `conversational` skip so `skills(skips=["conversational"])` still suppresses the whole block. - Adds authoring rules: do not declare the built-in graph, do not name a handler after the route it listens to, do not declare state unless it needs extra fields, and give every route handler a description. - Documents the declarative form in the conversational-flows guide across en, ar, ko and pt-BR, including what is supplied automatically, how to run it, and what a declaration cannot express (live LLM objects, a response_format class, route_turn overrides). - `crewai run` on a conversational declaration now says it has no chat loop and points at handle_turn/chat, instead of quietly running a single turn and exiting. It fails closed: a flow that cannot be inspected runs normally. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(flow): render the conversational router section in the skill Both conversational models shared one `Conversational` section, and the template renders only the first model of a non-union section. The router's fields were therefore dropped from the API reference and the generated link to them pointed at a heading that did not exist. Also softens the built-in-handler rule: `_extend_definition` keeps an author-supplied entry and the guide documents that override, so the skill should say to omit those handlers by default rather than never declare them. Adds regression tests for both sections rendering, for every field of both models appearing, and for `skips=["conversational"]` suppressing both. Both found by CodeRabbit on #7035. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(flow): correct the route-description rule in the authoring skill The rule said every route handler must define `description`, but `conversational.router.route_descriptions` is the higher-precedence source -- `_build_route_catalog` checks the overrides before falling back to the method description. Either one describes a route; the rule now says so, and says what happens when a route has neither. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: ViditOstwal <viditostwal@gmail.com> Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-08-19 20:18:18 +05:30
João Moura	01a156d738	feat(flow): synthesize the built-in conversational methods for declarations (#7033) ... * test(flow): unskip the conversational end-to-end suite The `conversational_graph_broken` marker parked 21 end-to-end conversational tests with the reason "the definition-first start migration intentionally stopped scanning inherited methods, so that graph no longer registers". That is no longer true: `_iter_flow_methods` walks the MRO for `__conversational_only__` methods (dsl/_utils.py:406-420), so a `conversational = True` subclass does register `route_conversation`, `converse_turn`, `end_conversation` and `answer_from_history_turn` — which `test_flow_definition.py:391-407` already asserts. Removing the marker takes the file from 47 passed / 21 skipped to 68 passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(flow): make conversational opt-in unmistakable Opting a Flow into chat took two statements, and forgetting one failed silently. With `@ConversationConfig(...)` but no `conversational = True`: `FlowDefinition.conversational` came back `None`, the built-in graph never registered, and `handle_turn()` returned `None` without appending a message or raising — while `chat()` reported "only available on conversational flows" on a class that was literally decorated with a conversational config. Three changes: - `ConversationConfig.__call__` now also sets `conversational = True`. Every field on the config is consumed only by the conversational graph, so a decorated non-conversational Flow could only ever discard it. - `FlowConversationalDefinition.enabled` defaults to True. The block is absent on non-conversational flows, so declaring it is the opt-in; `enabled: false` remains an explicit opt-out. - `handle_turn()` raises like `chat()` and `stream_turn()` already do instead of silently returning `None`. Setting `conversational = True` by hand still works and is still the way to opt in without a config. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(flow): let a declaration drive conversational mode `FlowDefinition.conversational` was written by the DSL projection and read by nothing: every conversational gate resolved through `type(self).flow_definition()` — the class projection — instead of `self._definition`, the declaration a flow was actually built from. So `Flow.from_declaration()` on a definition with a conversational block produced a flow that reported itself non-conversational, dropped the user message, and never registered its declared routes. Resolution rules, applied consistently: - Structure (enabled, methods, route labels, builtin/internal routes) comes from `self._definition`, which is the loaded declaration for a declarative flow and the class projection otherwise. Both paths now agree. - Behavior (`conversational_config`) still prefers the class attribute, which can hold live objects — a configured LLM, a custom BaseLLM, a response_format model class — that the serializable definition degrades to a config dict or a `module:qualname` ref. Reading the definition first would silently downgrade every decorated Python flow. A declaration-built flow has no class config, so `_config_from_definition` supplies one, cached for stable identity. - A declared `state:` block is never replaced. `_create_default_extension_state` is consulted before `_create_definition_state`, so returning `ConversationState` there discarded every field the declaration asked for. It now yields to a declared state and only supplies the default when nothing else does. The class-scoped `_is_conversational` / `_conversational_definition` classmethods are gone; the existing instance-scoped `_is_conversational_enabled` is the single gate. A router `response_format` that survived serialization as a ref or schema dict is dropped with a warning rather than handed to `llm.call()`, which needs a real class. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(flow): synthesize the built-in conversational methods for declarations A declaration carrying `conversational: {}` loaded clean and then ran zero methods and returned `None`, because the four built-in graph handlers are inherited from `_ConversationalMixin` and a declaration has nothing to inherit from. Authors had to name `crewai.experimental.conversational_mixin:_Conversational Mixin.route_conversation` and three siblings by hand. `Flow._extend_definition` is a new runtime extension hook, called once `_definition` is resolved and before methods are bound. The conversational mixin overrides it to fill in `route_conversation`, `converse_turn`, `end_conversation` and `answer_from_history_turn` when they are missing, using the same code refs the DSL projection already emits so a declaration and a class projection of the same flow produce identical method definitions. Synthesis is deliberately a runtime concern, not a contract one: `FlowDefinition` stays independent of the authoring layer and of the engine, as `test_flow_definition_contract_is_dsl_agnostic` requires, and a loaded declaration still serializes back to exactly what its author wrote. Route descriptions are now carried by the contract. The DSL projects a handler docstring's first line into `FlowMethodDefinition.description`, and the router catalog reads that before falling back to the live docstring. This also fixes a real defect: for a declarative flow `getattr(type(self), handler_name, None)` is `None`, and the old code read `None.__doc__` — so the router LLM was told a route's description was "The type of the None singleton." Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(flow): let an agent or crew handler reply in a conversation (#7034) `handle_turn` promotes a handler's return value to the assistant message when the handler did not append one itself, but the check required `isinstance(result, str)`. Declarative `agent` and `crew` actions return `LiteAgentOutput` and `CrewOutput`, whose text lives on `.raw` — so the most natural declarative handler was exactly the one whose reply never reached the transcript. `_is_public_turn_result` now unwraps `.raw` before deciding, matching `_stringify_result`, which already did. The routing-artefact guards are applied to the unwrapped text, so an output echoing a route label or this turn's intent is still not promoted. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(flow): keep privately recorded agent results out of the transcript Unwrapping `.raw` in `_is_public_turn_result` made the end-of-turn fallback promote `LiteAgentOutput` / `CrewOutput` objects that the handler had already recorded via `append_agent_result` with the default private visibility. That call does not set `_assistant_reply_appended`, so the fallback republished the very object the handler asked to keep private — defeating `visible_agent_outputs`. Reproduced against `main` for contrast: no leak before the unwrap, leak after. `append_agent_result` now remembers the object it recorded for the duration of the turn, and the fallback skips anything already routed that way. The check is identity-based on purpose: a handler that records scratch work privately and then returns a user-facing summary still gets that summary promoted, which a simple "handler already handled it" flag would have broken. Found by Cursor Bugbot on #7033. * feat(flow): mark a declarative chat flow conversational on the instance A declaration enables chat through `conversational.enabled`, without the `conversational = True` class attribute. Callers outside this package capability-check that attribute -- the AG-UI serving guide states it as a requirement -- so it disagreed with `_is_conversational_enabled()` and a declarative conversational flow looked non-conversational from outside. `_extend_definition` now sets it on the instance when the definition enables chat. Instance-only on purpose: the DSL projection reads the attribute off the *class* to decide whether to emit a conversational block, so setting it there would make every later subclass look conversational. Verified on a real declarative flow: `conversational` and `stream_turn` both now satisfy the documented capability check, while `Flow.conversational` and any later subclass stay False. * refactor(flow): derive routing-artefact labels from the effective routes `_is_public_turn_result` matched a literal set of route labels, duplicating knowledge that `_effective_builtin_routes()` already owns. A declaration that adds a builtin route was not covered, so a handler echoing that label could be promoted into the transcript -- the same class of divergence already fixed for `route_turn`. Verified the derived set is byte-identical to the old literal one for a class-based flow, so this is a pure generalization: `conversation` and `route_to_flow` stay explicit because neither is a route. Also replaces a tuple-index lambda in the chat REPL test with a named `input_fn`; it relied on tuple evaluation order and on the list being mutated before its length was read. Both found by CodeRabbit on #7033. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: ViditOstwal <viditostwal@gmail.com>	2026-08-19 20:03:11 +05:30
João Moura	6f16e741aa	feat(flow): let a declaration drive conversational mode (#7032) ... * test(flow): unskip the conversational end-to-end suite The `conversational_graph_broken` marker parked 21 end-to-end conversational tests with the reason "the definition-first start migration intentionally stopped scanning inherited methods, so that graph no longer registers". That is no longer true: `_iter_flow_methods` walks the MRO for `__conversational_only__` methods (dsl/_utils.py:406-420), so a `conversational = True` subclass does register `route_conversation`, `converse_turn`, `end_conversation` and `answer_from_history_turn` — which `test_flow_definition.py:391-407` already asserts. Removing the marker takes the file from 47 passed / 21 skipped to 68 passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(flow): make conversational opt-in unmistakable Opting a Flow into chat took two statements, and forgetting one failed silently. With `@ConversationConfig(...)` but no `conversational = True`: `FlowDefinition.conversational` came back `None`, the built-in graph never registered, and `handle_turn()` returned `None` without appending a message or raising — while `chat()` reported "only available on conversational flows" on a class that was literally decorated with a conversational config. Three changes: - `ConversationConfig.__call__` now also sets `conversational = True`. Every field on the config is consumed only by the conversational graph, so a decorated non-conversational Flow could only ever discard it. - `FlowConversationalDefinition.enabled` defaults to True. The block is absent on non-conversational flows, so declaring it is the opt-in; `enabled: false` remains an explicit opt-out. - `handle_turn()` raises like `chat()` and `stream_turn()` already do instead of silently returning `None`. Setting `conversational = True` by hand still works and is still the way to opt in without a config. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(flow): let a declaration drive conversational mode `FlowDefinition.conversational` was written by the DSL projection and read by nothing: every conversational gate resolved through `type(self).flow_definition()` — the class projection — instead of `self._definition`, the declaration a flow was actually built from. So `Flow.from_declaration()` on a definition with a conversational block produced a flow that reported itself non-conversational, dropped the user message, and never registered its declared routes. Resolution rules, applied consistently: - Structure (enabled, methods, route labels, builtin/internal routes) comes from `self._definition`, which is the loaded declaration for a declarative flow and the class projection otherwise. Both paths now agree. - Behavior (`conversational_config`) still prefers the class attribute, which can hold live objects — a configured LLM, a custom BaseLLM, a response_format model class — that the serializable definition degrades to a config dict or a `module:qualname` ref. Reading the definition first would silently downgrade every decorated Python flow. A declaration-built flow has no class config, so `_config_from_definition` supplies one, cached for stable identity. - A declared `state:` block is never replaced. `_create_default_extension_state` is consulted before `_create_definition_state`, so returning `ConversationState` there discarded every field the declaration asked for. It now yields to a declared state and only supplies the default when nothing else does. The class-scoped `_is_conversational` / `_conversational_definition` classmethods are gone; the existing instance-scoped `_is_conversational_enabled` is the single gate. A router `response_format` that survived serialization as a ref or schema dict is dropped with a warning rather than handed to `llm.call()`, which needs a real class. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: ViditOstwal <viditostwal@gmail.com> Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-08-19 19:03:11 +05:30
Lucas Gomide	dabd123528	fix: use the URL hostname as MCP HTTP and SSE server_name (#7048) ... Connection events used the raw endpoint as `server_name`, so traces titled the row with the full Bright Data URL including query params. HTTP and SSE `_get_server_info` now emit the hostname and keep the full URL on `server_url`.	2026-08-19 18:52:25 +05:30
João Moura	f0e00df036	feat(flow): make conversational opt-in unmistakable (#7031) ... * test(flow): unskip the conversational end-to-end suite The `conversational_graph_broken` marker parked 21 end-to-end conversational tests with the reason "the definition-first start migration intentionally stopped scanning inherited methods, so that graph no longer registers". That is no longer true: `_iter_flow_methods` walks the MRO for `__conversational_only__` methods (dsl/_utils.py:406-420), so a `conversational = True` subclass does register `route_conversation`, `converse_turn`, `end_conversation` and `answer_from_history_turn` — which `test_flow_definition.py:391-407` already asserts. Removing the marker takes the file from 47 passed / 21 skipped to 68 passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(flow): make conversational opt-in unmistakable Opting a Flow into chat took two statements, and forgetting one failed silently. With `@ConversationConfig(...)` but no `conversational = True`: `FlowDefinition.conversational` came back `None`, the built-in graph never registered, and `handle_turn()` returned `None` without appending a message or raising — while `chat()` reported "only available on conversational flows" on a class that was literally decorated with a conversational config. Three changes: - `ConversationConfig.__call__` now also sets `conversational = True`. Every field on the config is consumed only by the conversational graph, so a decorated non-conversational Flow could only ever discard it. - `FlowConversationalDefinition.enabled` defaults to True. The block is absent on non-conversational flows, so declaring it is the opt-in; `enabled: false` remains an explicit opt-out. - `handle_turn()` raises like `chat()` and `stream_turn()` already do instead of silently returning `None`. Setting `conversational = True` by hand still works and is still the way to opt in without a config. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 12:39:27 +05:30
Lucas Gomide	47fa48d787	fix: close the agent scope on every failed attempt (#6997) ... * fix: close the agent scope on every failed attempt `_check_execution_error` only emitted `AgentExecutionErrorEvent` once the retries were exhausted, but each retry re-enters `execute_task` and opens a new `agent_execution_started` scope. The scopes left open were then popped by the next ending event, so `task_failed` closed an agent scope instead of `task_started` and the task never got its own terminal pairing. Passthrough exceptions keep bubbling untouched, since a HITL pause must leave its scope open for the resume. * fix: return the retried result instead of finalizing it twice A retry reenters `execute_task`, whose own `_finalize_task_execution` already emitted `AgentExecutionCompletedEvent`, and the outer frame then finalized the same result again. The duplicate used to be absorbed by the `agent_execution_started` scope that a failed attempt left open, so closing every attempt exposed it: the extra completed event popped `task_started`, and the task and crew ends paired with the wrong scopes. --------- Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-08-19 11:37:33 +05:30
João Moura	b1c9c89ad0	fix(telemetry): attribute tool errors to the tool that failed (#7043) ... `Telemetry.tool_usage_error` has always accepted `tool_name` and writes the attribute when it is truthy, but no caller passed it, so every `Tool Usage Error` span landed with an empty name. Per-tool error rates were therefore not computable at all: named tools read zero errors while the unnamed bucket held all of them. Passes the tool name at the four sites where the tool is known. They are the same two failures in both execution modes - usage-limit and execution-error, each once in the sync `_use` and once in the async `_ause` - so the fix is symmetric across the sync/async matrix rather than four unrelated edits. Leaves the fifth site in `_tool_calling` unattributed on purpose, with a comment saying why: that path is a tool-call PARSING failure, so the tool the model wanted was never identified. The only string available is the raw, unparsed model output, and putting that into a metrics dimension would give it unbounded cardinality. An empty name is the honest representation there. Adds tests over the full matrix, including the parsing case pinning the opposite expectation. Verified they fail against the unpatched module: the four attribution tests fail and the parsing test still passes, which is the intended split. Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 23:29:19 -03:00
João Moura	7942ce0c76	test(flow): unskip the conversational graph end-to-end suite (#7030) ... The `conversational_graph_broken` marker parked 21 end-to-end conversational tests with the reason "the definition-first start migration intentionally stopped scanning inherited methods, so that graph no longer registers". That is no longer true: `_iter_flow_methods` walks the MRO for `__conversational_only__` methods (dsl/_utils.py:406-420), so a `conversational = True` subclass does register `route_conversation`, `converse_turn`, `end_conversation` and `answer_from_history_turn` — which `test_flow_definition.py:391-407` already asserts. Removing the marker takes the file from 47 passed / 21 skipped to 68 passed. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 01:00:05 +00:00
Lucas Gomide	2ebb9390fe	feat(mcp): carry the AMP slug on tools resolved from a slug reference (#7029) ... An MCP tool's name is derived from the server URL, so nothing on the resolved tool records which reference it was requested by. `MCPNativeTool` now keeps that reference as `server_reference` when `_resolve_amp` built it, leaving servers requested by URL untouched. Hooks can then attribute a tool call to the server the user actually selected.	2026-08-18 15:15:27 -04:00
Vidit Ostwal	6388421510	[OSS-128] Handle oversized single messages during chunking (#7014) ... * fix(OSS-128): split oversized messages before context chunking Normalize single messages that exceed the token budget before boundary chunking so summarization LLM calls do not replay the same context error. Reserve summarization prompt overhead from the chunk budget for large context windows. * refactor(OSS-128): inline message content text extraction as lambda * refactor(OSS-128): restore _message_content_text as a function Revert the lambda assignment to satisfy ruff E731 and keep the helper readable alongside the LLMMessage content shape. * refactor(OSS-128): drop summarization prompt overhead from chunk budget Use the full context window size for message chunking instead of subtracting a fixed prompt overhead. * fix(OSS-128): preserve LLMMessage fields when splitting oversized content Copy the original message attributes into each sub-message and only replace content when expanding oversized entries for chunking. * test(OSS-128): assert rendered summarization requests fit raw context Verify each chunked summarization payload, including system and instruction overhead, stays within the model limit implied by the 85% context window usage ratio.	2026-08-17 09:41:54 -07:00
Rip&Tear	9b1f4938f0	fix(tools): pin SSRF checks to each redirect hop and peer IP (#6981) ... * fix(tools): pin SSRF checks to each redirect hop and peer IP validate_url only inspected the original URL string, so scraping fetches could follow a 302 to an internal address or rebind DNS between check and connect. Route safe_get through an HTTPAdapter that re-validates every hop and connects to the authorised sockaddr, and let FORCE_SAFE_PATHS ignore a tenant-supplied escape hatch on managed workers. Co-authored-by: Rip&Tear <theCyberTech@users.noreply.github.com> * Potential fix for pull request finding 'Except block handles 'BaseException'' Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com> * test(azure): use a plain stand-in for Responses API delegate mocks MagicMock instances are not reliably stored on Pydantic PrivateAttr via BaseLLM.__setattr__, which left _responses_delegate as None and failed last_response_id / reset_chain assertions on CI. Co-authored-by: Rip&Tear <theCyberTech@users.noreply.github.com> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Rip&Tear <theCyberTech@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>	2026-08-17 13:08:03 +05:30
Rip&Tear	754d7323be	fix: native tool calls broken over OpenAI Responses API (#6515) ... * fix(agent): recognize OpenAI Responses API tool-call shape in native tool loop is_tool_call_list() and extract_tool_call_info() only recognized Chat-Completions-style ({"function": {...}}), Anthropic-style ({"name", "input"}), and Gemini-style tool-call shapes. The Responses API's function_call output items are flat dicts shaped {"id", "name", "arguments"} with no nested "function" key and no "input" key, so they matched none of the checks. This caused is_tool_call_list() to misclassify a genuine tool call as a plain text answer, so the native tool loop returned the raw tool-call list as the agent's final output instead of executing the tool. Even after recognizing the shape, extract_tool_call_info() would have passed an empty arguments dict, since it only read "input" for the dict fallback. Verified against LLM(api="responses") with tools attached: the agent now correctly executes the tool with the parsed arguments instead of returning the unexecuted tool-call JSON as its answer. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * test(agent_utils): cover OpenAI Responses API tool-call shape Regression tests for is_tool_call_list() and extract_tool_call_info() against the Responses API's flat {"id", "name", "arguments"} dict shape, alongside existing Chat-Completions and Bedrock/Anthropic shapes to confirm no regression there. Confirmed these tests fail against the pre-fix version of agent_utils.py (3 failures matching exactly the Responses API cases) and pass against the fix in 37087b7e1. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(llms/openai): convert Chat-Completions tool messages to Responses API input items _prepare_responses_params() passed non-system messages straight through as the Responses API "input" array without converting them. That's fine for plain user/assistant text (matches the API's lenient "easy input message" shape), but Chat-Completions-style assistant messages carrying "tool_calls" and "tool"-role messages have no equivalent shape in the Responses API - it expects standalone "function_call" and "function_call_output" input items instead. Sending the raw Chat-Completions shapes gets rejected with a 400 (union-type validation failure against every Responses API input item variant). This broke every multi-turn tool-calling conversation over api="responses" that doesn't rely on auto_chain/previous_response_id (i.e. the common case: resending full history each turn instead of referencing server-side state). Added _convert_message_to_responses_input_items() to translate: - assistant + tool_calls -> one function_call item per call - tool role -> function_call_output item - everything else -> passed through unchanged Verified against a real multi-turn tool-calling run: the agent now completes the full conversation and returns the actual extracted answer instead of erroring on the second turn. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(llms/openai): fix mypy list-item type error in message conversion _convert_message_to_responses_input_items() was annotated to return list[dict[str, Any]], but the passthrough branch returns the LLMMessage argument unchanged. Lists are invariant in mypy, so a bare LLMMessage (TypedDict) isn't assignable into a list[dict[str, Any]] return - this was flagged by CI's type-checker job across all Python versions. Widened the return type (and the local list built in the tool_calls branch) to list[dict[str, Any] | LLMMessage], matching what the function actually returns. Confirmed with a local mypy run and the full openai/agent_utils test suites (176 passed). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: harden Responses API tool call conversion * style: format Responses API conversion * fix: upgrade nltk to 3.10.0 to resolve path traversal vulnerabilities Upgrades nltk from 3.9.4 to 3.10.0 which fixes three path traversal vulnerabilities (GHSA-qvv7-cg9c-w4x3, GHSA-fg7f-2386-8897, GHSA-xh95-f55m-82fw) that were causing the pip-audit CI job to fail. Also removes the now-obsolete PYSEC-2026-597 ignore entry from the vulnerability-scan workflow since the vulnerability is fixed in 3.10.0. * fix: bump aiohttp to >=3.14.2 and cryptography to >=50.0.0 to fix pip-audit vulns Co-authored-by: theCyberTech <84775494+theCyberTech@users.noreply.github.com> * fix: default empty Responses tool-call arguments to {} Missing or empty Chat Completions tool-call arguments were forwarded as an empty string, which is invalid JSON for Responses API function_call items and breaks parse_tool_call_args. Normalize to "{}" and cover the case in regression tests. Also assert a supplied tool-call id is preserved as call_id. Co-authored-by: Rip&Tear <theCyberTech@users.noreply.github.com> * Removing fallback from call_id * Removing fallback from call_id --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: João Moura <joaomdmoura@gmail.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Rip&Tear <theCyberTech@users.noreply.github.com> Co-authored-by: ViditOstwal <viditostwal@gmail.com>	2026-08-13 21:27:35 -04:00
Lorenze Jay	852916c8bf	feat: bump versions to 1.15.16 (#6990)	2026-08-14 00:06:10 +00:00
João Moura	d74e647502	fix(core): record the running release on every emitted span (#6989) ... * fix(core): record the running release on every emitted span Nine of twenty-four span kinds never recorded crewai_version, including the two highest-volume ones - Task Created and Task Execution - plus Human Feedback, Flow Plotting, and the whole deployment family. add_crew_attributes writes crew_key, crew_id and crew_fingerprint but never the release, so any question filtered by version silently returned nothing for those spans and per-release comparison was blind to them. Add it at the fourteen sites that were missing it across both emitters, matching each module's existing convention: version("crewai") in crewai, get_crewai_version() with the file's local-import pattern in crewai_core. Guarded by a test that parses both modules and fails when any method creates a span without recording the release, so a span added later cannot reintroduce the gap. Verified non-vacuous: removing the attribute from one span makes it fail and names that method. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * test(core): count spans against release attributes, and cover both emitters Two review findings, both real. The guard only asked whether a method mentioned crewai_version anywhere, so a method opening two spans while recording the release on one of them passed. task_started is exactly that shape. It now counts start_span calls against _add_attribute(..., "crewai_version", ...) calls and fails when the second is smaller, naming the method and both counts. Verified non-vacuous: removing the attribute from Task Execution alone - which the previous version accepted - now fails with "task_started (2 span(s), 1 version attribute(s))". The behavioural cases only ever ran against crewai's emitter, because _emit builds that singleton, so the five changed crewai_core methods had no behavioural coverage at all. Added a parametrized case over all eight spans crewai_core emits, using the fixture already in that file - covering the three that already recorded the release as well, so a regression there is caught too. Also removed the function-local `import crewai`: the paths now come from inspect.getfile() on the two classes, which is both consistent with the file's existing import style and more direct than guessing the module layout. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 23:57:37 +00:00
Lorenze Jay	1818792fb1	feat(execution): introduce execution context management with UUID sup… (#6988) ... * feat(execution): introduce execution context management with UUID support - Added `execution.py` to manage execution UUIDs for tracking nested execution contexts. - Implemented `begin_execution` and `end_execution` functions to handle the lifecycle of execution contexts. - Updated `Crew` and `Flow` classes to utilize the new execution context management, ensuring proper tracking during execution. - Added tests for execution UUID creation, inheritance, and lifecycle management to ensure functionality and correctness. * feat(execution): enhance execution context management in Crew class - Introduced `begin_execution` and `end_execution` calls in the `Crew` class to manage execution tokens effectively. - Updated the `akickoff` method to ensure proper lifecycle handling of execution contexts. - Added tests to verify the creation and clearing of execution UUIDs during the `akickoff` process, ensuring correct behavior in various scenarios. * feat(execution): add execution_uuid to PendingFeedbackContext for flow resumption - Introduced `execution_uuid` to the `PendingFeedbackContext` class to maintain the UUID across flow pauses and resumes, ensuring traceability of execution contexts. - Updated the `Flow` class to utilize the new `execution_uuid` during execution management, enhancing the handling of paused flows. - Added tests to verify that the execution UUID is correctly persisted and restored during flow operations, ensuring consistent behavior across sessions. * refactor(execution): streamline execution UUID management and update tests - Removed the `ensure_execution_uuid` function to simplify UUID handling, consolidating logic into `begin_execution` and `end_execution`. - Updated the `clear_execution_uuid` function to ensure it correctly restores previous UUIDs using context tokens. - Modified tests to reflect changes in execution UUID management, ensuring proper creation, inheritance, and clearing of UUIDs during execution contexts. - Enhanced the `PendingFeedbackContext` documentation to clarify the handling of `execution_uuid` for pending rows.	2026-08-13 16:29:46 -07:00
João Moura	4b9b8bcbb9	feat(events): record what kind of exception ended a flow (#6982) ... * feat(telemetry): record what kind of exception ended a flow Flow failures are visible but undiagnosable. Live data shows roughly 17% of flows ending in outcome=failed, and 72% of AgentExecutor failures completing in under 200ms - far too fast to be an LLM call - but nothing records what the failure actually is, so there is no way to tell a real defect from a user pressing Ctrl-C. Record the exception's class name as error_type on Flow Completed and Flow Method Failed. The class name only: str(error) is never read, because it routinely carries prompts, model output, file paths and credentials. The isidentifier() check is the allowlist that enforces it - any message text reaching that argument carries a space or punctuation and is dropped - and it lives inside Telemetry rather than at the call site so a future caller cannot bypass it. Method names and flow state remain unrecorded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * docs(frontend): point the frontend guides at their edge paths The frontend guides added in #6686 exist only under edge - they are not in any frozen version snapshot - but their 80 internal links use the bare /en/guides/frontend/... form, which resolves against the released versions where those pages do not exist. mint broken-links fails on every one of them, which blocks every open PR, not only the one that added them. Use the /edge/en/... form the repo already uses for other edge-only pages (concepts/streaming, learn/execution-boundary-hooks). Anchors are preserved. No page content changes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-13 16:12:19 +00:00
Rip&Tear	5d7ae87177	fix mysql search table name validation (#6341)	2026-08-13 14:10:01 +08:00
João Moura	77a929ecf5	feat(tracing): record when a trace batch is shared with amp (#6966) ... * feat(tracing): record when a trace batch is shared with amp A trace batch is sent to AMP on every traced run, but nothing on the OSS side recorded that it happened, so a project's first touch with AMP was invisible in telemetry. Emit a Feature Usage span on successful finalization: tracing:ephemeral_sent before the user has an account, tracing:authenticated_sent after. Emitted on finalize rather than init because a batch that initializes and then fails to send never lands in AMP. Reading is_ephemeral from batch state at finalize also means a run that starts authenticated and falls back to ephemeral on a 401 reports ephemeral, which is what happened. Rides the existing Feature Usage span, so no new pipeline is needed to read it, and it carries project_id and coding_agent for free through the common attributes processor. Records only that a batch arrived - never trace contents, crew or flow names, inputs, or outputs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * docs(telemetry): disclose the attributes the trace signal carries The new row said only that a batch arrived was recorded, which reads as excluding the common attributes every span carries. project_id and the coding assistant are disclosed in the Execution Environment row, but "only" actively contradicted that. Name them here too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-12 09:46:11 -07:00
João Moura	93d7a07422	feat(telemetry): count deployments from any origin and record where they started (#6974) ... Deployments were only countable through two span types that no aggregation reads, and cli_usage:deploy counted the TUI button rather than deployments. Emit deploy:created and deploy:pushed alongside the existing spans so a deployment is countable from the feature-usage aggregation no matter how it was started, and tag Create Crew Deployment / Start Deployment with source=cli|tui so the two origins stay distinguishable. Separately, the TUI's `t` and `d` key bindings dispatch straight to action_view_traces / action_deploy_crew, which never recorded anything - only on_button_pressed did. Every keyboard-driven trace view and deploy was therefore invisible. Move the recording into the actions, which both input paths funnel through, and past the completed guard so a mid-run keypress that does nothing is not counted as usage. Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-12 15:41:59 +00:00
João Moura	8b646620be	fix(events): stop a failed turn from marking the next one failed (#6965) ... * fix(telemetry): stop a failed turn from marking the next one failed A conversational session that opts out of deferred finalization ends each turn with its own FlowFailedEvent, emitted inside kickoff() before handle_turn() emits ConversationTurnFailedEvent. The flag was therefore set after the run that owned it had already cleared it, survived on the instance, and reported the next healthy turn as failed. Gate the flag on the run still having its start stamp: a deferring session keeps it (no per-turn terminal event), so it still reports a failed turn at session end. Also aligns the Flow Lifecycle Signals privacy row with the rest of the telemetry table, which qualifies every user-authored field it records with "should not include personal info", and fixes a telemetry test that built InputResponse with an unsupported `value` keyword - ask() swallowed the TypeError, so the test asserted the signals while exercising the provider-error path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(telemetry): cover the streamed turn emitter of the failure flag stream_turn() is the second emitter of ConversationTurnFailedEvent and leaks the same flag as handle_turn(). Both regression tests fail on 77c68bd with ['failed', 'failed']. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-12 20:59:19 +05:30
João Moura	7d2437cf85	feat: bump versions to 1.15.15 (#6962) ... * feat(flow): report flow outcome and human-in-the-loop signals A flow reported only that it started. FlowFinishedEvent, FlowFailedEvent, MethodExecutionFailedEvent, MethodExecutionPausedEvent and FlowPausedEvent all reached the console formatter and stopped there, and FlowInputRequestedEvent, FlowInputReceivedEvent and ConversationTurnFailedEvent had no listener at all - so success rate, failure rate and every HITL pause were unmeasurable. Adds flow:completed, flow:failed, flow:method_failed, flow:paused, flow:hitl_paused, flow:input_requested, flow:input_received and flow:conversation_turn_failed as feature-usage spans, which the existing feature-usage aggregation already reads. Deliberately does not hold the Flow Execution span open to measure duration: flow_executions_daily_target counts those spans at start, so a run that never finishes would disappear from the count entirely. Duration needs its own span. Counts only - flow names, method names, error text and flow state are never recorded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * feat(flow): record how long a flow ran Adds a Flow Completed span carrying flow_name, duration_ms and outcome, emitted when a flow finishes or fails. Elapsed time comes from a monotonic stamp taken at flow start and cleared on use. Kept separate from the Flow Execution span rather than holding that one open: it is emitted and closed at start and the daily aggregate counts it, so holding it would drop every run that is killed or crashes from the execution count. A killed run now simply has no Flow Completed row, and the count is unaffected. Elapsed time is an explicit duration_ms attribute rather than the span's own duration, which the ingestion pipeline stores as a suffixed string ("0.0000184s") that downstream aggregation parses to zero. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * feat(flow): tag flow origin and report resumed runs Two gaps found while testing the pause/resume path end to end. Resumed runs were invisible. There is no resume event: a restored run re-enters through kickoff(), so it looked identical to a fresh start. flow:resumed is derived from _is_execution_resuming at flow start, which makes flow:paused - flow:resumed the abandonment rate. Flow counts are dominated by CrewAI's own AgentExecutor, which is itself a Flow and runs once per agent execution - it is the top flow in the warehouse by a wide margin. Nothing distinguished it from a user's flows except guessing at the name. Both Flow Execution and Flow Completed now carry origin: "internal" when the flow class is defined under crewai.*, "user" otherwise. Tagging only the new span would have left the existing daily count unsplittable. Both span methods take origin with a default, so their signatures stay backward compatible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * fix(flow): scope outcome and resume signals to user flows Two findings from review, both confirmed against the code. Outcome features counted CrewAI's own flows. The agent executor, memory encoding and memory recall are all Flows and all set suppress_flow_events; they run far more often than anything a user wrote, so flow:completed, flow:failed and flow:method_failed were mostly bookkeeping. Those three are now emitted only for flows the caller wrote. Internal outcomes are still recorded on the Flow Completed span, which carries origin. flow:resumed counted checkpoint restores. _is_execution_resuming is set both by from_pending (a human pause) and by a checkpoint restore that never paused for anyone, so resumes could exceed pauses and the abandonment rate was unusable. Keyed off _pending_feedback_context instead, which only from_pending sets. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * fix(flow): declare internal flows instead of inferring them Three findings from review, all confirmed against the code. Gating on suppress_flow_events was wrong. That flag asks for console quiet and is a public field, so a caller who set it on their own flow silently lost flow:completed, flow:failed and flow:method_failed. Deciding origin from the defining module was also wrong. Flow.from_declaration() returns a Flow typed in crewai.flow.flow, so a caller's declarative flow was reported as one of CrewAI's own - the inversion this split exists to prevent. Both had the same root cause: the discriminator was inferred. Flow now declares is_crewai_internal, set on the agent executor and the memory encoding/recall flows, and one helper serves both origin and the outcome gate. A failed conversational session was reported as completed. Its session closes with FlowFinishedEvent whatever happened, so a failed turn produced flow:conversation_turn_failed and flow:completed together. The turn failure is now recorded on the flow and read back when the session finishes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * refactor(flow): report flow lifecycle as spans, not feature usage Flow start, completion, pause and method failure are lifecycle facts, and the lifecycle is reported as spans everywhere else. Reporting them through feature usage put them in a table that aggregates on the feature string alone - it cannot carry origin, duration or outcome, so those signals could never be split between a user's flows and the ones CrewAI runs for itself. Adds Flow Paused and Flow Method Failed spans, and a resumed marker on Flow Execution so a run restored from a pause is not counted as a second fresh start. Removes the duplicate feature rows for completed, failed, method_failed, paused and resumed - every one of those facts is now on a span, with more attached to it than the feature row ever carried. Feature usage keeps only genuine adoption signals: flow:hitl_paused, flow:input_requested, flow:input_received and flow:conversation_turn_failed. Also clears the conversational turn-failure flag on every terminal path. A turn that failed without deferred finalization ends via FlowFailedEvent, and the flag left set there marked the next run on that instance as failed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * test(flow): update the flow_execution_span caller for the resumed argument Adding the resumed marker changed a signature that tests/utilities/test_events.py asserts on exactly, and that assertion was not re-run before pushing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * test(flow): make the checkpoint-restore guard actually guard The test asserted that flow:resumed was absent from feature usage, but that signal moved onto the Flow Execution span. The assertion could no longer fail, so a regression that mis-tagged checkpoint restores as resumes would have gone unnoticed. Now asserts the resumed attribute, and waits for the handlers: the manual emit dispatches asynchronously, so the previous shape also read its result before the listener had run. Confirmed it discriminates - keying resumed off _is_execution_resuming again fails it with [('RestoredFlow', True)] == [('RestoredFlow', False)]. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * fix(telemetry): record the resumed marker as a string Verified end to end against the live collector and ClickHouse: the pipeline encodes a boolean attribute as the presence of a vBool key, so false arrives as the key simply being absent. That is invisible in the schema and easy to read wrongly - crew_memory is extracted as "the attribute exists" and consequently reports 1 for 99.8% of crews against a field that defaults to False. A string leaves nothing to infer. Confirmed in the warehouse: the emitted span reads resumed = "false". Adds direct coverage for the attributes each flow span records, including both resumed values, and resets the Telemetry singleton in the helper so more than one span method can be exercised per session. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * feat: bump versions to 1.15.15 --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 22:13:41 -03:00
João Moura	7642e615a3	feat(flow): report flow outcome, duration and human-in-the-loop signals (#6961) ... * feat(flow): report flow outcome and human-in-the-loop signals A flow reported only that it started. FlowFinishedEvent, FlowFailedEvent, MethodExecutionFailedEvent, MethodExecutionPausedEvent and FlowPausedEvent all reached the console formatter and stopped there, and FlowInputRequestedEvent, FlowInputReceivedEvent and ConversationTurnFailedEvent had no listener at all - so success rate, failure rate and every HITL pause were unmeasurable. Adds flow:completed, flow:failed, flow:method_failed, flow:paused, flow:hitl_paused, flow:input_requested, flow:input_received and flow:conversation_turn_failed as feature-usage spans, which the existing feature-usage aggregation already reads. Deliberately does not hold the Flow Execution span open to measure duration: flow_executions_daily_target counts those spans at start, so a run that never finishes would disappear from the count entirely. Duration needs its own span. Counts only - flow names, method names, error text and flow state are never recorded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * feat(flow): record how long a flow ran Adds a Flow Completed span carrying flow_name, duration_ms and outcome, emitted when a flow finishes or fails. Elapsed time comes from a monotonic stamp taken at flow start and cleared on use. Kept separate from the Flow Execution span rather than holding that one open: it is emitted and closed at start and the daily aggregate counts it, so holding it would drop every run that is killed or crashes from the execution count. A killed run now simply has no Flow Completed row, and the count is unaffected. Elapsed time is an explicit duration_ms attribute rather than the span's own duration, which the ingestion pipeline stores as a suffixed string ("0.0000184s") that downstream aggregation parses to zero. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * feat(flow): tag flow origin and report resumed runs Two gaps found while testing the pause/resume path end to end. Resumed runs were invisible. There is no resume event: a restored run re-enters through kickoff(), so it looked identical to a fresh start. flow:resumed is derived from _is_execution_resuming at flow start, which makes flow:paused - flow:resumed the abandonment rate. Flow counts are dominated by CrewAI's own AgentExecutor, which is itself a Flow and runs once per agent execution - it is the top flow in the warehouse by a wide margin. Nothing distinguished it from a user's flows except guessing at the name. Both Flow Execution and Flow Completed now carry origin: "internal" when the flow class is defined under crewai.*, "user" otherwise. Tagging only the new span would have left the existing daily count unsplittable. Both span methods take origin with a default, so their signatures stay backward compatible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * fix(flow): scope outcome and resume signals to user flows Two findings from review, both confirmed against the code. Outcome features counted CrewAI's own flows. The agent executor, memory encoding and memory recall are all Flows and all set suppress_flow_events; they run far more often than anything a user wrote, so flow:completed, flow:failed and flow:method_failed were mostly bookkeeping. Those three are now emitted only for flows the caller wrote. Internal outcomes are still recorded on the Flow Completed span, which carries origin. flow:resumed counted checkpoint restores. _is_execution_resuming is set both by from_pending (a human pause) and by a checkpoint restore that never paused for anyone, so resumes could exceed pauses and the abandonment rate was unusable. Keyed off _pending_feedback_context instead, which only from_pending sets. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * fix(flow): declare internal flows instead of inferring them Three findings from review, all confirmed against the code. Gating on suppress_flow_events was wrong. That flag asks for console quiet and is a public field, so a caller who set it on their own flow silently lost flow:completed, flow:failed and flow:method_failed. Deciding origin from the defining module was also wrong. Flow.from_declaration() returns a Flow typed in crewai.flow.flow, so a caller's declarative flow was reported as one of CrewAI's own - the inversion this split exists to prevent. Both had the same root cause: the discriminator was inferred. Flow now declares is_crewai_internal, set on the agent executor and the memory encoding/recall flows, and one helper serves both origin and the outcome gate. A failed conversational session was reported as completed. Its session closes with FlowFinishedEvent whatever happened, so a failed turn produced flow:conversation_turn_failed and flow:completed together. The turn failure is now recorded on the flow and read back when the session finishes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * refactor(flow): report flow lifecycle as spans, not feature usage Flow start, completion, pause and method failure are lifecycle facts, and the lifecycle is reported as spans everywhere else. Reporting them through feature usage put them in a table that aggregates on the feature string alone - it cannot carry origin, duration or outcome, so those signals could never be split between a user's flows and the ones CrewAI runs for itself. Adds Flow Paused and Flow Method Failed spans, and a resumed marker on Flow Execution so a run restored from a pause is not counted as a second fresh start. Removes the duplicate feature rows for completed, failed, method_failed, paused and resumed - every one of those facts is now on a span, with more attached to it than the feature row ever carried. Feature usage keeps only genuine adoption signals: flow:hitl_paused, flow:input_requested, flow:input_received and flow:conversation_turn_failed. Also clears the conversational turn-failure flag on every terminal path. A turn that failed without deferred finalization ends via FlowFailedEvent, and the flag left set there marked the next run on that instance as failed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * test(flow): update the flow_execution_span caller for the resumed argument Adding the resumed marker changed a signature that tests/utilities/test_events.py asserts on exactly, and that assertion was not re-run before pushing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * test(flow): make the checkpoint-restore guard actually guard The test asserted that flow:resumed was absent from feature usage, but that signal moved onto the Flow Execution span. The assertion could no longer fail, so a regression that mis-tagged checkpoint restores as resumes would have gone unnoticed. Now asserts the resumed attribute, and waits for the handlers: the manual emit dispatches asynchronously, so the previous shape also read its result before the listener had run. Confirmed it discriminates - keying resumed off _is_execution_resuming again fails it with [('RestoredFlow', True)] == [('RestoredFlow', False)]. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * fix(telemetry): record the resumed marker as a string Verified end to end against the live collector and ClickHouse: the pipeline encodes a boolean attribute as the presence of a vBool key, so false arrives as the key simply being absent. That is invisible in the schema and easy to read wrongly - crew_memory is extracted as "the attribute exists" and consequently reports 1 for 99.8% of crews against a field that defaults to False. A string leaves nothing to infer. Confirmed in the warehouse: the emitted span reads resumed = "false". Adds direct coverage for the attributes each flow span records, including both resumed values, and resets the Telemetry singleton in the helper so more than one span method can be exercised per session. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-12 00:42:09 +00:00
Lucas Gomide	65a4b7cede	fix: emit FlowStartedEvent when a boundary hook aborts the flow (#6953) ... * fix: emit FlowStartedEvent when a boundary hook aborts the flow A HookAborted at EXECUTION_START or INPUT propagated before `FlowStartedEvent` was emitted, so a policy deny left logs but no record of the execution. On abort, stamp the state id and open the flow scope before re-raising: the deny surfaces as a started -> failed execution while normal runs keep the existing ordering — the started event carries hook-resolved inputs and `id` rewrites keep redirecting persistence restoration. * docs: translate execution-boundary-hooks page to ar, ko, and pt-BR The English page updated on this branch had never been localized. Translate it into the three supported locales following `DOCS_TRANSLATIONS.md` and register the page in each locale's navigation in `docs/docs.json`. Untranslated link targets (the step-hooks page and the aborting-an-operation anchor) are omitted rather than pointed at English, matching the locale navigation convention.	2026-08-11 11:54:27 -07:00
Lorenze Jay	6c19669d63	refactor: update date injection functionality in agents (#6850) ... * refactor: update date injection functionality in agents - Changed the description of the parameter to clarify that it injects the current date into the agent's prompt instead of tasks. - Removed the method as it was no longer needed. - Implemented a new method in the class to handle date injection directly into the prompt. - Updated tests to ensure the date is correctly injected into the system prompt and user messages based on the flag. * translations * nit	2026-08-11 14:36:47 -03:00
Vidit Ostwal	11890e6701	Standardize CLI flags to kebab-case (#6880) ... * Standardize CLI flags to kebab-case with deprecated snake_case aliases. Unify active long-option naming across create, train, test, and replay while keeping hidden backward-compatible aliases and documenting the migration in edge docs and AGENTS.md. * Emit deprecation warnings when snake_case CLI flag aliases are used. Route hidden legacy flags through separate internal params so warnings fire only when the alias is supplied, and extend CLI tests for create, replay, and --help coverage. * Merge CLI deprecation warn helpers into warn_deprecated(kind=...). Replace warn_deprecated_command and warn_deprecated_flag with one helper that accepts kind="command" or kind="flag".	2026-08-11 22:17:24 +05:30
João Moura	094b94e8d0	fix(core): scope span export to our own tracer provider (#6954) ... * fix(telemetry): stop exporting third-party spans to the collector set_tracer() installed CrewAI's TracerProvider as the global one, so every OTel-instrumented library in the host process - HTTP servers, Redis clients, ORMs - resolved trace.get_tracer() to our provider and exported to CrewAI's endpoint. A 20M-row sample of the telemetry table found 18,866 distinct operation names under our serviceName; CrewAI emits 21. The same wiring lost data in the other direction: when an application had already installed its own provider, our spans were created by theirs and went to their collector, so CrewAI received nothing from instrumented processes. Spans are now created from the private provider in both packages. Deletes _attach_common_attributes and its WeakSet/lock, whose multi-provider dedupe guarded a state that can no longer occur. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * fix(telemetry): keep process context on crewai-core spans Isolating each package to its own TracerProvider removed an accident the CLI spans depended on: crewai_core.telemetry had no CommonAttributesSpanProcessor, so its spans only ever carried coding_agent/runtime_context/project_id by riding the global provider that crewai installed at import. A differential capture of every span reaching the exporter showed 8 of 54 spans losing those attributes - Feature Usage (cli_usage:*), Start Deployment, Template Installed, Create Crew Deployment, Get Crew Logs, Remove Crew, Deploy Signup Error and Flow Creation. Moves the marker tables and the detect_* helpers to crewai_core.runtime_env and the processor plus common_span_attributes() to crewai_core.telemetry, so both implementations share one source of truth. crewai.telemetry.utils and crewai.utilities.constants re-export the moved names, so their import paths are unchanged. Also fixes a gap that predates the isolation change: a CLI-only process never imports crewai, so it never reported either attribute. It does now. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * fix(core): type test helpers and stop tests reaching the collector mypy runs over lib/crewai-core/tests (the one test tree not excluded), so the new test file needed full annotations and a narrowed span.attributes. Also patches SafeOTLPSpanExporter before Telemetry is constructed and shuts the provider down afterwards: __init__ wires a BatchSpanProcessor around the real OTLP exporter, so each test was attempting a live export and leaving its batch worker thread running. Corrects the marker-precedence docstring, which named Cursor third when the table checks it last so that assistants running inside its terminal are not masked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * style(core): use one import form per module in telemetry tests Both test modules imported their telemetry module twice - once aliased for the monkeypatch target and once via from-import for the names. Dropping the alias in favour of monkeypatch's dotted-string target leaves a single import form and removes the need to qualify every reference. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH * docs(core): drop comments that restate the code The TRACER_NAME constants were annotated with what their name and set_tracer()'s docstring already say, and the test fixtures narrated provider.shutdown() and the exporter patch at more length than either needed. Keeps the ones carrying something the code cannot: the resource-attribute ingestion quirk, why the marker tables moved packages, and the two ordering traps the fixtures exist to avoid. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ASfWmW3RGy4qAQm6s8U9jH --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-11 00:16:27 +00:00
Rip&Tear	17f107c197	fix(deps): bump gitpython to 3.1.58 in crewai-tools[github] (#6885) ... gitpython 3.1.57 has GHSA-9rj7-rf2p-w77r, GHSA-4gmw-gg2m-w46p, GHSA-hh9p-6wh2-4mfc, GHSA-wvpp-8hx9-p66j and GHSA-jm78-9fvv-mhgr (further unguarded git option forwarding / arbitrary file read via --pathspec-from-file). All are fixed in 3.1.58, which the root override-dependencies already require; align the crewai-tools github extra with it and regenerate the lockfile.	2026-08-09 13:25:26 -07:00
João Moura	752a2a9c0a	feat: bump versions to 1.15.14 (#6876)	2026-08-08 19:55:33 -03:00
João Moura	92012aec55	feat: split runtime context from coding agent, add project id (#6867) ... * feat(telemetry): split runtime context from coding agent, add project id The coding-agent field answered two questions at once. A run with no TTY reported "non_interactive" and an editor's integrated terminal reported "vscode_terminal", both in the same field as the assistant name, so a run that never had an assistant to detect was indistinguishable from one whose assistant we failed to recognize. Together those two values were the majority of what the field reported. detect_coding_agent now answers only which assistant, returning "unknown" when no marker matches. detect_runtime_context answers where the process runs: ci, serverless, hosted_ide, notebook, container, the editor terminals, and the interactive/non_interactive fallback. Both ride on every span, so an assistant running inside CI reports both rather than one masking the other. The runtime markers are published platform contracts - CI providers, container and serverless runtimes, hosted IDEs - so unlike the assistant table they need no per-tool verification step. Presence is checked; no value is read. The assistant table is unchanged: its entries still require a confirmed, session-scoped variable, and the existing guard test still enforces that. Spans also carry project_id when the project declares one. It is read through the read-only accessor, since minting an id belongs to the CLI commands a user invoked rather than to a library call during execution, and it is omitted entirely for projects without one. The attributes are computed once per process and memoized, so the project file is not re-read for each provider. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs: document execution environment telemetry attributes Adds the execution-environment row to the data table in en, ar, ko and pt-BR. Covers the assistant and runtime fields this branch splits apart and the project id, and states that detection reads only whether known environment variables are set. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(telemetry): detect runtime markers by presence, split paas from serverless Three findings from the CodeRabbit, code-quality and Cursor reviews. The runtime loop tested truthiness while constants.py documented presence, so a platform exporting a bare CI= fell through to the TTY fallback and was mislabelled as an ordinary local run. Presence is now what it says. The assistant markers keep truthiness deliberately: there an empty value means the tool set a placeholder rather than claiming the session. DYNO and WEBSITE_INSTANCE_ID marked Heroku dynos and Azure App Service instances as serverless, and since serverless is checked first they could never reach the container label. They move to a paas context, which is what they are: long-lived containers rather than per-invocation functions. AWS_EXECUTION_ENV is dropped entirely - it is set on ECS and EC2 as well as Lambda, and AWS_LAMBDA_FUNCTION_NAME already covers Lambda without the collision. The container probe no longer wraps os.path.exists in a try/except. os.path.exists handles OSError internally and returns False, so the handler guarded a condition that cannot occur and only hid the intent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(telemetry): widen assistant detection from published marker sets The table previously covered three assistants because the rest were unverified. They are documented after all: vercel/detect-agent publishes a machine-readable detection matrix (agents.json), corroborated by the proposal in agentsmd/agents.md#136 and by microsoft/vscode#311734. Adds cline, gemini_cli, augment, opencode, antigravity and junie, plus CLAUDE_CODE alongside CLAUDECODE. Gemini's marker is confirmed by its own docs, which state that run_shell_command sets GEMINI_CLI=1 in the subprocess environment. Rule 2 excluded several entries those sources list. Goose's GOOSE_PROVIDER and Copilot's COPILOT_MODEL and COPILOT_GITHUB_TOKEN are user configuration, and a committed .env carrying one would relabel every ordinary run - the AIDER_MODEL trap the guard test already pins, now parametrized over all four. Replit's REPL_ID names a hosted environment rather than an assistant, so it stays a runtime context. Copilot sets no session marker at all today; that is an open request upstream. The new assistants are ordered ahead of Cursor, since CURSOR_* is set for every integrated terminal and would otherwise mask anything spawned inside it - the same ordering Codex already needed. Also adds the proposed cross-vendor AI_AGENT marker as a last resort, reported as "other". It establishes that an assistant is present without naming one, and its value is an arbitrary vendor string, so the value is never read. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(deps): raise gitpython and pypdf floors for new advisories gitpython 3.1.57 carries GHSA-9rj7-rf2p-w77r, GHSA-4gmw-gg2m-w46p, GHSA-hh9p-6wh2-4mfc, GHSA-wvpp-8hx9-p66j and GHSA-jm78-9fvv-mhgr: further unguarded git option forwarding in Repo.init, read-tree and git-config, plus arbitrary file read via --pathspec-from-file. Fixed in 3.1.58. pypdf 6.14.2 carries GHSA-fwg2-594c-jp42 and GHSA-fp3f-mc75-235c, unbounded runtime and memory on large content and /ToUnicode streams. Fixed in 6.15.0. Both floors were already pinned, so only the versions move. Their exclude-newer-package cutoffs had to move with them - 3.1.58 landed 2026-08-04 and 6.15.0 on 2026-08-06, both past the existing dates, so the resolver could not have seen either release. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(telemetry): share assistant precedence with the env-context path Four findings from the Cursor and CodeRabbit reviews, three of them the same root cause. get_env_context restated the precedence the shared table already defines, so every marker added for telemetry was invisible to it: a session exposing only CLAUDE_CODE reported claude_code on spans while emitting DefaultEnvEvent, and an assistant running inside a Cursor terminal reported that assistant on spans while emitting CursorEnvEvent. It now walks CODING_AGENT_ENV_MARKERS and maps the three assistants that have an event class of their own, defaulting the rest to DefaultEnvEvent. A test now asserts the two paths agree for every marker in the table, so they cannot drift again. The generic AI_AGENT marker was documented as presence-only but ran through the truthiness loop with everything else, so an empty value fell through to unknown. It moves out of the table and is checked by presence after it, which also keeps the named markers' truthiness intact. Azure Functions run on the App Service host and inherit WEBSITE_INSTANCE_ID, so moving that marker to paas would have relabelled them. The FUNCTIONS_* markers are checked first to keep them serverless. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(telemetry): stop export assertions depending on test order test_all_common_attributes_land_on_exported_spans failed in CI with an IndexError on an empty span list, and only in one shard: the suite runs with OTEL_SDK_DISABLED set, so TracerProvider hands out no-op tracers and an export-based assertion sees zero spans rather than a wrong attribute. It passed only when it happened to run after a test whose fixture flips the variable, which random ordering decides. Adds an otel_enabled fixture that sets the variable for the four tests asserting on exported spans. Three of them predate this branch and had the same latent dependency - they are fixed here because the new test made the ordering hit reachable, and leaving them would keep the required check red. Verified by running every test in the file individually, all of which previously exposed the dependency, and the telemetry suite three times under random ordering. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-07 17:28:52 -07:00
João Moura	42e041146e	feat: bump versions to 1.15.13 (#6865)	2026-08-07 21:10:19 +00:00
Lucas Gomide	e264e058a7	fix: preserve provider on LiteLLM-routed models (#6849) ... * fix: preserve provider on LiteLLM-routed models LiteLLM construction computed the real provider in `__new__` but never passed it into init, so `BaseLLM` silently defaulted every shared-path model to `openai`. Infer the provider from a `provider/model` prefix when none is supplied so groq, cohere, mistral, and the rest report themselves correctly to callers like the policy engine. * fix: avoid double-prefixing instructor model strings With LiteLLM models now carrying a real `provider` while `model` keeps its `provider/name` form, `InternalInstructor` was building `groq/groq/...` for `instructor.from_provider`. Skip the prefix when the model string is already qualified. * fix: format LiteLLM multimodal content as OpenAI-shaped blocks Preserving the real provider on the LiteLLM path made `format_multimodal_content` emit Anthropic-native blocks for `anthropic/...` models, which LiteLLM rejects. Keep `provider` as the model identity for policies, but format multimodal blocks with the OpenAI chat schema when `is_litellm` is set. Expose the formatter helper on `BaseLLM` so native OpenAI/Azure completions share the same API.	2026-08-07 11:20:28 -04:00
Lucas Gomide	34230a0182	fix: harden brittle LLM event-bus mocks (#6861) ... * fix: patch the event-bus singleton in usage event tests `TestEmitCallCompletedEventPassesUsage` mocked `CrewAIEventsBus.emit` on the class, but `_emit_call_completed_event` calls the `crewai_event_bus` singleton. Under CI that left the real bus emitting and the mock never seeing a call. Patch the singleton where `base_llm` imports it instead. * fix: harden llm call-failed event test against VCR fallback `test_llm_emits_call_failed_event` marked VCR while mocking `_handle_completion`, and its cassette recorded a successful reply. When the class-level patch missed under xdist, VCR replayed success and the expected exception never fired. Patch the instance method and drop the cassette so the failure path cannot silently succeed. * fix: patch the event-bus singleton instance in emit mocks `patch.object(CrewAIEventsBus, "emit")` misses callers when an instance-level `emit` shadows the class method — common under xdist after other suites touch the singleton. Patch `crewai_event_bus.emit` on the shared instance instead across the LLM event mock fixtures.	2026-08-07 19:23:32 +05:30
Vidit Ostwal	988f060c93	Fix Anthropic cache token usage underreporting (#6844) ... * Fix Anthropic native provider to include cache tokens in input totals. Anthropic reports cache read and cache creation separately from input_tokens; fold them into input_tokens and total_tokens so billed usage is not underreported on cached workloads. * Reconcile unreconciled Anthropic cache tokens in UsageMetrics. LiteLLM and flow event paths can pass raw Anthropic usage where input_tokens excludes cache counters; fold them into prompt and total tokens without double-counting native provider payloads. Co-authored-by: Cursor <cursoragent@cursor.com> * Document UsageMetrics token field semantics for flows and crews. Clarify that total_tokens is prompt plus completion, breakdown fields are not additive, and Anthropic cache counters are folded into prompt_tokens. Co-authored-by: Cursor <cursoragent@cursor.com> * Document Anthropic cache token accounting in LLM provider docs. Explain how split Anthropic input counters map to UsageMetrics and link to the flows field semantics section. Co-authored-by: Cursor <cursoragent@cursor.com> * Restore cache_creation_tokens breakdown in UsageMetrics normalization. Keep cache writes as a separate breakdown field while they remain folded into prompt_tokens for billed totals. * Replace cross-page doc links with plain-text section references. Avoid internal hyperlinks between concept pages for SEO; point readers to section names in prose instead. * Apply ruff formatting to usage metrics helpers. * Sync ar, ko, and pt-BR docs for Anthropic usage metrics updates. Translate UsageMetrics semantics and Anthropic cache token accounting changes in crews, flows, and llms concept pages. --------- Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-07 17:07:02 +05:30
João Moura	10583d6ee3	feat: bump versions to 1.15.12 (#6835)	2026-08-05 19:49:52 -03:00
Lorenze Jay	b1b6f6f539	feat(devtools): bump Flow canary on release (#6830)	2026-08-05 15:46:51 -07:00
João Moura	0c74f23596	feat(tools): add URLReadTool for reading arbitrary URLs (#6834) ... * feat(tools): add URLReadTool for reading arbitrary URLs FileReadTool is confined to the local filesystem, so there was no way for an agent to read a document that lives behind an http(s) URL. Rather than adding a flag to FileReadTool, this adds a separate tool: granting it grants network egress to addresses an LLM picks at runtime, and that should be a deliberate choice rather than a toggle on a filesystem tool. URLReadTool fetches a URL and returns its content as text. PDF and DOCX bodies have their text extracted, HTML is stripped to visible text, and text-shaped types (plain text, Markdown, JSON, XML, YAML, CSV) are decoded using the charset the server declares. Any other content type is refused rather than returned as base64, keeping the output text-only. Requests reuse the existing SSRF protections in security/safe_requests: validate_url resolves every hostname and rejects private, loopback, link-local and reserved addresses (covering cloud metadata endpoints), and safe_get never auto-follows redirects, revalidating each hop and dropping credentials on cross-origin ones. Resolving before validating also normalizes encoded forms, so http://2130706433/ is rejected as 127.0.0.1 without needing a string blocklist. Adds safe_get_bounded on top of that, which streams the body and abandons it once it crosses max_bytes. The cap counts decoded bytes, which is what a compressed response expands into -- Content-Length describes the wire size and cannot bound that. It also closes the redirect hops, which stream=True would otherwise leave holding their connections. Two risks are documented rather than closed. Validation resolves the hostname and requests resolves it again to connect, so DNS rebinding remains possible; closing it needs the connection pinned to the validated address, which would change behavior for all existing safe_get callers. And the returned text is untrusted remote content entering an agent's context, which input validation cannot address. Also fixes a temp file leak in PDFLoader, which reached the same pymupdf-from-URL path. It wrote downloads to NamedTemporaryFile with delete=False and never unlinked them, so every PDF ingested from a URL left a file behind. It now opens from memory, the way URLReadTool does, which removes the leak by construction instead of relying on cleanup on each error path; its doc.close() also moves into a finally so a failure mid-extraction still releases the handle. PDFLoader had no test file, so this adds one covering both paths plus a regression test asserting no temp file is created. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tools): address review feedback on URLReadTool Bound start_line and line_count with ge=1 in the args schema. Both were unbounded, and _window computes stop as start + line_count, so a negative line_count reached islice, which rejects a negative stop. The windowing runs outside the tool's error handling, so that escaped _run as a raw ValueError instead of an error string. BaseTool.run validates kwargs against args_schema, so the constraint refuses the value before any request is made. _window also clamps its own bounds now, so it cannot raise if called directly. Bound the PDFLoader download with safe_get_bounded. The body is held in memory for the whole extraction, so it needed a ceiling; it defaults to 50 MiB and takes a max_bytes kwarg to load() for callers ingesting larger documents. Patch the loader's own seam in its tests rather than requests.get. Both safe_get and safe_get_bounded resolve the hostname before requesting, so the previous mocks made the tests depend on DNS for example.com and fail in a network-isolated runner for reasons unrelated to the loader. Exercise the content-type fallback through run() rather than asserting on _resolve_kind, so the tests survive a refactor of the classification internals, and cover the octet-stream PDF, missing-type, query-string and unknown-extension cases as observable behavior. Add docstrings to the new tests. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tools): close streamed redirect hops and widen type fallback Four findings from the Copilot and Cursor reviews. safe_get leaked its accumulated hops on every failure path. It closed the response it was about to abandon but not the ones already in history, and a caller handed an exception has no handle on them -- under stream=True each holds its connection until its body is read or closed. The loop now closes history before re-raising. Hops are still the caller's on success, where they arrive via response.history. safe_get_bounded rejected a non-positive max_bytes only after issuing the request, and then reported it as an oversized body. It now fails before the request. Its oversized-body error also named the requested URL rather than the one that served the body, which differ after a redirect. The content-type fallback consulted only the final URL for an extension, so a .pdf link redirecting to an extensionless CDN or presigned path was refused even though the requested URL identified the type. It now checks the final URL first, then the requested one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 19:38:36 -03:00
Lucas Gomide	53def96b53	feat: add app metadata to platform action tools (#6832) ... * feat: add app metadata to platform action tools Platform policy matching needs an explicit integration slug on every `CrewAIPlatformActionTool` at runtime. The builder now propagates each API app key and tests cover the resulting tool metadata. Co-authored-by: Cursor <cursoragent@cursor.com> * refactor: remove redundant platform tool app assignment `CrewAIPlatformActionTool` already receives `app` through Pydantic during base initialization. Remove the duplicate assignment to retain one owner for field state. --------- Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-05 18:13:01 -04:00
Vidit Ostwal	319a20c028	docs: update scaffold AGENTS.md for unified create CLI (#6829) ... Document crewai create tool/skill/template, lifecycle commands, and deprecated-but-supported scaffolding aliases in the project template AGENTS.md. Remove the no-op --skip_provider flag from the flow example.	2026-08-06 01:10:19 +05:30
Vidit Ostwal	8320178697	fix(flow): clarify conversational route/handler name collision errors (#6825) ... * fix(flow): clarify route/handler name collision validation errors When @listen(...) includes the handler's own name, FlowDefinition validation fails. This change improves the error text and how it surfaces for Python Flow classes. What changed - _self_listen_error in flow_definition.py: two message variants (conversational vs default), both include the listen condition - build_flow_definition in dsl/_utils.py: wraps FlowDefinition ValidationError with the Python Flow class name - Tests for declarative and DSL-built flows; docs follow in a separate commit When each error surfaces 1. Conversational message — FlowDefinition validation when conversational.enabled is true and listen references the handler name. Example: @listen("create_video") on def create_video in a conversational flow. Surfaces via: - FlowDefinition.from_declaration(dict/yaml) → pydantic ValidationError for FlowDefinition (Value error, methods.create_video.listen listen condition...) - MyFlow.flow_definition() / MyFlow() → ValueError Invalid flow definition for MyFlow: ... (wrapped by pydantic as ValidationError for MyFlow on instantiation) 2. Default (non-conversational) message — same trigger check when the flow is not conversational. Example: @listen("publish") on def publish. Surfaces via the same paths as (1). 3. Class-name wrapper — only on the Python DSL path when build_flow_definition catches FlowDefinition ValidationError. Prepends Invalid flow definition for {ClassName}: to the underlying message from (1) or (2). Does not apply to from_declaration without a Flow class. * docs(flow): explain conversational handler naming vs route labels Document why @listen route labels must differ from handler method names and recommend the handle_* naming pattern. * docs(cli): warn against matching @listen labels to handler names Add AGENTS.md guidance for crew and flow scaffolding so coding assistants do not name handlers the same as their @listen route or event labels. * docs(cli): clarify @listen self-reference fails at validation Document that matching @listen labels to handler names raises a validation error at flow instantiation, and that the runtime loop only occurs if validation is bypassed.	2026-08-06 00:14:55 +05:30
Vidit Ostwal	fef32f43a0	feat(cli): unify scaffolding under crewai create <resource> (#6821) ... * feat(cli): add canonical `crewai create tool` command Unify tool scaffolding under the create verb and deprecate `crewai tool create` with a yellow warning while keeping backward compatibility. * feat(cli): add canonical `crewai create skill` command Unify skill scaffolding under the create verb and deprecate `crewai skill create` with a yellow warning while keeping backward compatibility. * feat(cli): add canonical `crewai create template` command Unify template scaffolding under the create verb and deprecate `crewai template add` with a yellow warning while keeping backward compatibility. * docs: document unified `crewai create` scaffolding commands Document canonical create forms for tool, skill, and template projects, note deprecated aliases, and update skills and agents-md guides. * feat(cli): extend create picker and DMN guidance for all types Show tool, skill, and template in the interactive create picker and list every supported type in the CREWAI_DMN usage error. * fix(cli): allow create tool/skill/template in CREWAI_DMN mode Only set skip_provider in DMN mode for crew creation, since tool, skill, and template paths reject that flag as a crew-only option. * test(cli): patch TemplateCommand at cli lookup site in DMN test create() resolves TemplateCommand from crewai_cli.cli, not from remote_template.main directly.	2026-08-05 16:41:27 +00:00
João Moura	a60d36a8df	feat: bump versions to 1.15.11 (#6816)	2026-08-04 22:52:54 -07:00