833 Commits

Include renames

Author	SHA1	Message	Date
Wilson_Jiang	b523e6124f	docs: fix dead repo links in observability guides (Braintrust SDK, OpenInference) (#8310)	2026-10-20 21:34:47 +05:30
Rip&TearandClaude Sonnet 5.5	c08008b624	fix(tools): default-deny non-global IPs in SSRF check (#7826) ... * fix(tools): default-deny non-global IPs in SSRF check is_blocked_ip used hand-written denylists that missed CGNAT (100.64.0.0/10, incl. Alibaba metadata 100.100.100.200), 198.18.0.0/15, Azure WireServer (168.63.129.16), and IPv6 forms wrapping private IPv4 (NAT64, 6to4). Block anything that is not is_global, keep explicit entries for ranges is_global may allow or that vary by Python version, and unwrap IPv4-mapped and NAT64 (64:ff9b::/96) addresses so the embedded IPv4 is checked. 6to4, Teredo and local-use NAT64 are non-global and blocked. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> * docs(tools): note CGNAT is blocked by SSRF-safe scrape tools Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> * fix(tools): block IPv6 transition ranges explicitly in is_blocked_ip 6to4 and local-use NAT64 were is_global=True before the CVE-2024-4032 fix (Python <3.10.15 / <3.11.10), so they relied on the interpreter to be blocked. Add them, Teredo, IPv4-compatible (::/96), IPv4-translated (::ffff:0:0:0/96) and deprecated site-local (fec0::/10) to the explicit IPv6 list, which also closes forms is_global allows on every version. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-10-20 10:52:08 +05:30
Lorenze Jay	d06c91401f	feat(flow): add opt-in per-turn conversation tracing (#8291) ... * feat(flow): add opt-in per-turn conversation tracing * fix(flow): avoid completing turns paused for human feedback	2026-10-20 10:19:59 +05:30
João MouraandClaude Opus 5.5	3da49f872b	feat(cli): crewai eval runs the crew itself, so a coding agent gets a verdict from one command (#8270) ... * feat(cli): crewai eval runs the crew itself, so a coding agent gets a verdict from one command Most `crewai eval` attempts stopped before an evaluation began because the project had no traced run. Telemetry since Sept 25: 117 projects stopped as "untraced", 97 of them with no terminal (coding agents), and 67 of those never got further. With no terminal the command could only print steps, and without a login those steps could not work: an unattended anonymous run never uploads its trace. - With no traced run, or when the project's files changed since the last one, `crewai eval` runs the crew and evaluates that run. No question, with or without a terminal: running the command is the request to have the run graded, and the grade is read off its trace. Tracing is on for that run only; nothing is written to the project's `.env`. - crewAI's tracing approves the upload of that run through the existing handshake: a token in CREWAI_EVAL_AWAITING_RUN that counts only while its file exists in the user's crewAI data folder, so a `.env` cannot claim it. Shared as `crewai_core.eval_handshake`; the run app keeps its own copy because it also runs against a project's older crewai-core, and a test pins the two. - The run app's Evaluate on an untraced run closes the app and runs the crew again, traced, through `crewai eval`'s own path, instead of a notice. - Counts: `eval_ran_crew:{no_traced_run,project_changed,run_again}`, `eval_finished:{passed,failed,inconclusive,unknown}`, and `eval_stopped:untraced_after_run` replacing the catch-all `untraced` (`declined` is gone with the question). The CLI tests no longer send usage counts. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(cli): a project that turned tracing off is asked before crewai eval runs it `CREWAI_TRACING_ENABLED=false` is the project's no, and nothing overrules it, not even a run `crewai eval` started. - `crewai eval` at a terminal asks to turn tracing on before running the crew. A yes writes it to the project's `.env`; a no runs nothing (exit 0, `eval_stopped:declined`). With no terminal it stops and says how to turn it on (`eval_stopped:tracing_off`), which a coding agent can do itself. - The run app's Evaluate on an untraced run asks the same question in a modal (TurnTracingOnScreen) before running the crew again. Otherwise it still runs it again with no question. - crewAI's tracing respects an explicit off again: `should_enable_tracing` checks it before a run `crewai eval` started, and `execution._tracing_disabled` is back to what main has. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(tracing): the telemetry opt-out no longer turns tracing off; an evaluated run says where its trace goes - `OTEL_SDK_DISABLED` is the telemetry opt-out, a separate setting from tracing, which has its own (`CREWAI_TRACING_ENABLED`, `tracing=`). `execution._tracing_disabled` no longer reads it. The trace session's own TracerProvider records even when the OpenTelemetry SDK is switched off (`session._trace_provider`), because the SDK otherwise hands out tracers that record nothing. A provider a host passes in is left as it is. Tests that used `OTEL_SDK_DISABLED` as a way to stop a trace now cover the two real switches; new tests show a traced run, anonymous or logged in, recorded and uploaded with it set. - A run app opened to run the crew for an evaluation (`crewai eval`, or Evaluate on a run that was not traced) shows one plain note on mount: "This run will be evaluated: its trace is sent to CrewAI AMP, which grades it." Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(cli): say where the trace goes only when the yes is inferred from crewai eval The note, in the run app ("This run will be evaluated: its trace is sent to CrewAI AMP, which grades it.") and in `crewai eval`'s line, is for the case where nobody turned tracing on: not `tracing=True` on the crew or flow, not `CREWAI_TRACING_ENABLED=true`, not a consent a person gave once (`crewai_core.user_data.is_tracing_enabled`), and not the yes they just gave to turn it on. A project or a person who opted in is told nothing new. The run `crewai eval` starts no longer sets `CREWAI_TRACING_ENABLED=true`: the handshake alone turns tracing on for it, so the setting a run reads is the project's own. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(cli): turn tracing on once with a note, pin the eval handshake, and keep the saved login to trusted AMPs From the review on #8270, and João's call on the note: - The first `crewai eval` that infers the yes turns tracing on for the project (`CREWAI_TRACING_ENABLED=true` in `.env` and for the run) and says so once, in the command and in the run app: "Tracing is now on for this project…". Afterwards the project traces and nothing more is said. A run whose crew or flow sets `tracing=False` is never told its trace is sent. - The handshake's folder is found from the account's home in the account database, never `HOME` or `XDG_DATA_HOME`, so a project's `.env` cannot plant a token file that approves an upload. Both copies (crewai-core, the run app) are pinned to the same folder and file by a test. - The token file carries the AMP origins `crewai eval` trusted before the project's `.env` was loaded. A run it started sends the saved login only there over HTTPS or loopback; an AMP the `.env` chose gets an anonymous grant. - Evaluate on an untraced run carries that run's definition, inputs (prompted ones included) and trained-agents file into the re-run. The conversational flow consumes the request too, and a crew or flow that sets `tracing=False` says why it cannot be evaluated instead of paying for another run. - "The project changed" also sees deleted files: each evaluation keeps the list of the project's files (`.crewai/eval_project_state.json`) and the next one compares against it. That list is taken after this command's own project-id write, so the write is no change. - The OpenTelemetry override probes its provider and warns if an SDK version still records nothing, instead of failing silently. - The stale `sdk` case of `test_disabled_execution_does_not_collect_or_request_grants` is gone; the handshake tests are typed (type-checker CI). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(cli): keep the saved login off a project's AMP on every path crewai eval runs From the second review round on #8270: - Evaluate's re-run runs in a process that already loaded the project's `.env`, so it passes this machine's AMPs (`_machine_amp_origins`) as the trusted set instead of reading `CREWAI_PLUS_URL` there (`eval_crew( trusted_amp_origins=…)`). - A project's `.env` can neither set nor replace `crewai eval`'s token: `run_crew.load_project_env` keeps the token the process was started with and drops one a `.env` sets. The JSON-crew, declarative-flow and eval paths all load `.env` through it. - `crewai eval` turns tracing on only when every credential this machine holds (the saved login, or a PAT or integration token from before the `.env`) may go to the AMP the run would trace to. A project's crewai older than the handshake would otherwise send it to an AMP the `.env` names. A newer crewai still traces the run anonymously through the handshake. - A conversational flow named by its definition is re-run by that definition. - Code quality: no redundant assignment in `_awaiting_dir`, no unused names in the credential test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(cli): crewai eval does not run a crew whose trace would carry the login to an untrusted AMP When tracing is on for the run (the project's .env, or a consent given once) and a credential of this machine would go to an AMP the command does not trust, the crew is not run. A project's crewai older than the handshake would send the login there, and the CLI cannot tell which crewai the project runs. The command stops (`eval_stopped:untrusted_amp`) and says how to go on: log in to that AMP, or remove CREWAI_PLUS_URL from the project's .env. A project that turned tracing off is not asked to turn it on toward such an AMP. With no credential on the machine, there is nothing to protect and the run goes on. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Ask at a terminal before tracing is first turned on A person running `crewai eval` at a terminal, in a project that never turned tracing on, is now asked on crewAI's trace consent screen before the crew runs; a yes turns tracing on for the project, a no (or the screen timing out) runs nothing and is counted as `declined`. The run app's Evaluate on an untraced run asks on its own consent screen the same way. With nobody at a terminal (a coding agent, a script) the yes is still inferred from the command, tracing is turned on and said once. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Keep main's Iterator import, which the rebase over #8187 dropped Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * A run-app test no longer leaves .crewai/last_eval.json in the repo Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Two run-app tests from #7963 no longer leave .crewai/last_eval.json in the repo Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Never run the crew toward an AMP the login must not reach; check before asking `crewai eval` now refuses to run the crew whenever a credential of this machine would go with the trace to an AMP it does not trust, whatever the tracing setting: `tracing=True` in code is invisible to the CLI, and a project's crewai older than the handshake sends the credential wherever the run traces. The run app's Evaluate makes the same check before it asks anything, so a yes can never write CREWAI_TRACING_ENABLED=true to `.env` for a re-run that is then refused. Which credentials are this machine's is read from the environment as it was before any project `.env` was loaded (`run_crew.environment_before_project`), so on Evaluate's re-run a CREWAI_USER_PAT the project's own `.env` brought is the project's, as on any run of it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Run the crew only toward an AMP this machine trusts, login or not Whether this machine holds a login right now no longer decides: with no login yet, `crewai eval` still wrote CREWAI_TRACING_ENABLED=true toward a CREWAI_PLUS_URL the project's `.env` chose, and the first run after `crewai login` would have carried the login there. Toward an AMP this command does not trust, the crew is now never run, nobody is asked and nothing is written, in `crewai eval` and the run app's Evaluate alike. That also drops the credential bookkeeping from b26ccaf44, which the rule no longer needs. The telemetry docs no longer say OTEL_SDK_DISABLED turns off everything: it disables OpenTelemetry instrumentation and CrewAI's telemetry, not AMP tracing, which has its own switches. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Pin that a project's own token never blocks Evaluate's re-run Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-19 04:11:15 -03:00
Vidit Ostwal	c661df9816	feat(agents): promote AgentExecutor out of experimental (#8192) ... * feat(agents): promote AgentExecutor out of experimental The default executor was still imported from crewai.experimental. Move it to a stable module and keep the old import as a deprecation warning. * fix(agents): stabilize executor discriminator * feat(agents): remove CrewAgentExecutor AgentExecutor is the only executor. Selecting the deleted class fails immediately, with no compatibility path. * feat(agents): drop experimental AgentExecutor compatibility The experimental import path and the legacy experimental discriminator are no longer accepted. * docs: address executor review comments Translate the remaining hook comments, document the full executor type, and stop the removal test from hiding an eager export. * docs: keep translated hook sketches on AgentExecutor The locale class sketches only needed the CrewAgentExecutor rename. LiteAgent and None stay on the English page, which documents the full type.	2026-10-15 14:33:38 -07:00
João Moura	eb15c66cef	[docs-freeze] docs: snapshot and changelog for v1.15.28 (#8147)	2026-10-14 01:46:47 -03:00
João MouraandClaude Opus 5.5	75808b0eca	fix(flow): learn from resumed human feedback and keep the reviewed output's type (#8142) ... * fix(flow): learn from human feedback that resumes a paused flow With learn=True, lessons were distilled only when the reply arrived during the same run. A reply that resumes a paused flow (resume / resume_async after from_pending, which is how async providers such as AMP's email review work) went through outcome collapse and routing but never reached _distill_and_store_lessons, so it taught nothing. Resume now stores lessons under the same conditions as an in-run reply: memory available, non-empty feedback, the method's learn_source and learn_strict, and the persisted LLM config. Both paths share one helper. A strict distillation failure fails the resume before the pending review is cleared, so it can be retried. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(flow): undo the recorded reply when strict learning fails on resume _finalize_human_feedback appends the reply to human_feedback_history and sets last_human_feedback before lessons are stored. With learn_strict, a distillation failure re-raises and the review stays pending, so a retry on the same instance recorded the reply twice. Restore both on failure. Lesson storage stays after outcome collapse, so a collapse failure never leaves lessons behind to be stored again on retry. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(flow): keep the reviewed output's type when learn=True pre-reviews it Pre-review always returned PreReviewResult.improved_output, a str, so a method returning a Pydantic model or a dict reached the reviewer, and last_human_feedback.output, as a repr string. Text output is still rewritten as text; a Pydantic model is now rewritten as the same model (response_model=type(output)); other outputs are shown unchanged. LiteLLM-routed models return structured output as a JSON string, which PreReviewResult/DistilledLessons.model_validate rejected, so pre-review and lesson storage silently did nothing for them. One parser now accepts an instance, a JSON string, or a dict. Docs (en, ar, ko, pt-BR): drop the nonexistent learn_limit, document learn_source and learn_strict, say lessons are also learned from replies that resume a paused flow, how each output type is pre-reviewed, and that downstream steps should read last_human_feedback.output. Correct the HumanFeedbackResult.output docstring and the learn/learn_strict field descriptions. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(flow): keep pre-review failures and unseen fields from leaking into the output model_dump_json() ran before the pre-review try, so a Pydantic output that cannot be serialized failed the feedback step even with learn_strict off. It now runs inside the try and falls back to the original output. A reviewed Pydantic model is rebuilt from what the LLM saw, so a SecretStr (sent masked) or an excluded field (not sent) came back as the mask or the default. Fields the review left unchanged now keep their original values. Also pin that a retry after a persistence failure that follows lesson storage offers the lessons to memory again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(flow): keep nested hidden values when pre-review edits sibling fields The unchanged-field restore only looked at top-level fields, so editing a sibling inside a nested model, or one item of a list of models, kept the LLM's masked secret and default excluded values for that whole object. The restore now recurses into nested models and same-length lists of models. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(flow): skip pre-review for models holding secrets or excluded fields Restoring hidden values after the review kept growing edge cases: aliased fields compared by name discarded the review's edit, dicts of models were not recursed, and reordered lists paired the wrong items, which could copy one account's secret onto another. Drop the merge. A Pydantic output is pre-reviewed only when the LLM sees all of it; one holding a Secret, SecretStr, SecretBytes or Field(exclude=True) value at any depth reaches the reviewer unchanged. Docs updated in en, ar, ko and pt-BR. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs(flow): say a resumed review's Pydantic output arrives as a dict PendingFeedbackContext persists method_output as JSON, so after from_pending and resume, last_human_feedback.output is a dict even when the method returned a model. The docstring and docs said "same type" without that qualification. Also say learn_strict covers distillation and submitting lessons, not the background memory write. Pin the dict behavior with a pause/resume test. Docs in en, ar, ko and pt-BR. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-14 03:05:26 +00:00
Nora Reidy	c0eda9f538	docs: consolidate MongoDB documentation improvements (#8097) ... * docs: consolidate MongoDB documentation improvements Combines previously closed MongoDB docs PRs (#6847, #6845, #6721, #6626, #6760, #6759) into a single PR per the updated contribution guidelines requiring a linked open issue. RagTool only supports chromadb and qdrant as vector store backends; MongoDB Atlas is covered separately by MongoDBVectorSearchTool, which is already listed in the database-data tools overview, so the RagTool data-sources bullet was dropped rather than reintroduced. Fixes #8096 * revert gemini change * ai review feedback * memory wording * translations	2026-10-13 11:36:15 +05:30
João MouraandClaude Opus 5.5	ab423144c1	docs: correct deploy and platform-tool guidance in the project AGENTS.md (#8084) ... * docs: correct deploy and platform-tool guidance in the project AGENTS.md The AGENTS.md that `crewai create` ships told coding agents that `crewai deploy remove <id>` works (the CLI only takes `-u <uuid>`), that a deploy needs a GitHub repository (with no origin it uploads a ZIP), that PLATFORM_APPS is the source of truth for action selectors (some of its action names resolve to no tool), and to measure quality with `crewai test`. Its router example also declared no labels, so `crewai flow plot` could not draw the branches. - Template: platform token, selector syntax, `apps:` YAML example and selector check; router labels; deploy prerequisites, `-y`, `.env` upload, org commands, `project_id`; best practice points at `crewai eval` inside the eval markers. - Docs: quickstart deploy prerequisite and `remove -u`, and router labels in concepts/flows, in en, ar, ko and pt-BR. - Tests parse every documented deploy/org command against the real CLI, run the routing example through the plot builder, and check the best practices stay numbered without gaps for crew and tool projects. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: base the quickstart ZIP-deploy note on any git origin The CLI deploys from git whenever an `origin` exists, GitHub or not, and uploads a ZIP only when there is none. The quickstart said "GitHub origin ... without one", which reads as if a non-GitHub origin takes the ZIP path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 22:22:59 +00:00
João MouraandClaude Opus 5.5	744bf60367	fix(cli): show why a deployment failed and fix deploy remove and lockfile checks (#8083) ... * fix(cli): show why a deployment failed and fix deploy remove and lockfile checks - deploy status prints AMP's error_message and error_suggested_fix when a deployment has failed, verbatim (no Rich markup), instead of only "Provisioning Failed, try again." - deploy remove -u names the removed UUID instead of the local project, and a failed removal prints the API's error. - deploy validate asks `uv lock --check` (offline) whether uv.lock is current instead of comparing file times, which flagged metadata-only edits that `uv lock` never clears. File times remain the fallback without uv or for poetry.lock. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: note that deploy status prints the failure reason Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(cli): print deploy validate findings without Rich markup render_report printed codes, titles, details and hints as Rich markup, so bracketed text vanished: `[stale_lockfile]`, `[project]`, `[tool.hatch.build.targets.wheel]`, `crewai[tools]`. Raw `uv` stderr in the new unverified_lockfile detail could also raise MarkupError on a stray closing tag. Escape every finding field. Also bound the test fixture's `uv lock` with a timeout. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 17:21:16 -03:00
Lorenze Jay	6b93fa0e25	[docs-freeze] docs: snapshot and changelog for v1.15.27 (#8004)	2026-10-09 19:33:27 -03:00
Melanie Hart Buehler	140bfcb89a	docs(rag): add XPU to OpenCLIP provider device options (#7923)	2026-10-09 14:05:39 +00:00
Georgi AtsevandJoão Moura	d38ceafb68	feat(llms): add deepinfra as an openai-compatible provider (#7459) ... * feat(llms): add deepinfra as an openai-compatible provider Register deepinfra in the OpenAI-compatible provider registry so LLM(model="deepinfra/<org>/<model>") routes natively with DEEPINFRA_API_KEY and no LiteLLM install. Model ids keep their org/model form, DEEPINFRA_BASE_URL overrides the endpoint, and the docs accordion is added in en, ar, ko and pt-BR, stating that the provider uses the native OpenAI client and needs no LiteLLM install. The model id check requires exactly one slash with both parts non-empty, and it also runs on the explicit provider="deepinfra" path, where a malformed id raises a ValueError that shows the expected form. deepinfra/ model strings previously routed through LiteLLM; is_litellm=True keeps that path. * fix(llms): reject malformed deepinfra/ ids before the LiteLLM fallback A deepinfra/<model> reference that is not org/model fell through to LiteLLM, so the same bad id failed later and differently depending on what was installed. The prefixed form now raises the same ValueError as provider="deepinfra", with the example and the echoed value written the way the caller wrote the id; both branches share one helper. --------- Co-authored-by: João Moura <joaomdmoura@gmail.com>	2026-10-09 05:12:19 -03:00
João Moura	bb235ef172	[docs-freeze] docs: snapshot and changelog for v1.15.26 (#7962)	2026-10-08 18:45:30 -03:00
Lorenze Jay	1d4015439a	[docs-freeze] docs: snapshot and changelog for v1.15.25 (#7946)	2026-10-07 18:51:56 -05:00
Lorenze Jay	d5efc45847	[docs-freeze] docs: snapshot and changelog for v1.15.24 (#7942)	2026-10-07 10:39:31 -07:00
Lorenze Jay	c6bf5ef5d4	feat(flow): queue relevant background replies (OSS-192) (#7911) ... * feat(flow): queue relevant background replies (OSS-192) * fix(flow): fence queued output after shared reply interruption * fix(flow): keep prepared delivery retries side effect free	2026-10-07 09:18:05 -07:00
Lorenze JayandVidit Ostwal	19d4154b0b	feat(flow): add experimental turn and reply identities (OSS-197) (#7909) ... * feat(flow): introduce experimental turn and public reply identities This update adds a new module for handling public replies within an existing conversational flow. It introduces the `TurnRunner`, which manages the lifecycle of turns and replies, allowing for experimental features such as tracking input revisions and reply identities. The changes include new classes for `TurnRecord`, `ReplyRecord`, and `TurnState`, enhancing the flow's capabilities while maintaining backward compatibility with existing APIs. Additionally, tests have been added to ensure the functionality of the new features. * fix docs * fix(flow): preserve live turn state and terminal events * fix(flow): remove redundant failure terminal marker --------- Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-10-07 13:56:34 +05:30
Lorenze Jay	738c8e19e3	feat(flow): add experimental job lifecycle and runner (#7864)	2026-10-02 17:03:54 -07:00
Lorenze Jay	deaa71e168	[docs-freeze] docs: snapshot and changelog for v1.15.23 (#7805)	2026-09-28 21:14:14 +00:00
Lorenze Jay	7a01af2791	[docs-freeze] docs: snapshot and changelog for v1.15.22 (#7521)	2026-09-16 15:09:40 -07:00
3 people	5990ead5ec	feat(cli): record why a deployment create failed (#7451) ... * feat(cli): record why a deployment create failed `crewai deploy create` counts every attempt (`Create Crew Deployment`) and every success (`Crew Deployment Created`), but the gap between them carried no cause: among clients able to emit the success span, the CLI succeeds 96.7% of the time and the run TUI 36.4%, and nothing said why. A third span, `Crew Deployment Failed`, now fires for every failure after the attempt is counted, with a closed vocabulary `reason` (api_4xx, api_5xx, invalid_response, network_error, zip_error, user_declined, unexpected), the HTTP `status_code` when the API answered, and the existing `source`. Never the error message. The request path is factored into `_request_crew_creation`; every exception is classified, reported and re-raised unchanged, so CLI and TUI behaviour is the same as before. HTTP failures are classified before `_validate_response`, which still prints and exits as it did. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(cli): classify deploy create failures by status and by stage Review fixes on the failure span. Check the HTTP class before the body so a gateway's HTML page counts as api_4xx / api_5xx with its code. Treat a 2xx whose body is not a JSON object carrying uuid and status as invalid_response and exit cleanly, instead of emitting a success span and crashing in the display step. Recognise archive failures by a dedicated ArchiveError (a ValueError) raised from create_project_zip, so the git helpers' own ValueErrors no longer read as zip_error; a failed ZIP write is wrapped and its partial file removed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(cli): treat staging and temp-file failures as archive errors `create_project_zip` only wrapped the ZIP write, so an `OSError` while staging files or creating the temporary archive escaped as a bare `OSError` and the deploy command recorded it as `unexpected` instead of `zip_error`. The archive boundary now covers staging, temp-file creation and the write; the staging directory is removed on every path, and no partial archive is left behind. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * feat(cli): tell a non-JSON 2xx apart from a non-creation 2xx A proxy's 200 HTML page and a JSON body missing the creation fields were both recorded as `invalid_response`. They are different failures, one in the network path and one in the API contract, so the deploy failure span now records `invalid_json` for the first and `invalid_creation_response` for the second. Requested in review. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-09-16 23:37:14 +05:30
João MouraandClaude Fable 5.1	6b6a39d503	fix(events): Improve coding agents instructions (#7447) ... * feat: scaffold project with assistant instruction files - Updated project creation to include `CLAUDE.md` and `GEMINI.md` that import `AGENTS.md`, ensuring consistent guidance across coding assistants. - Implemented utility functions to copy assistant instruction files during project setup. - Enhanced documentation in `AGENTS.md` to emphasize the importance of keeping telemetry enabled for optimal performance. - Added tests to verify the correct scaffolding of assistant instruction files and their contents. * fix(cli): neutral observability guidance in scaffolded AGENTS.md - State the observability rule as the user's decision, never a fix for console warnings, speed, or a "clean" configuration - Rewrite the AMP section as built-in capabilities: no "free", "proactively", "sales pitch", or scripted pitches - Turn the research mandate into a list of sources to consult when version details matter - Retarget the scaffold tests to the new wording Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(cli): scaffold assistant files for JSON crews and harden telemetry tests - create_json_crew, the default `crewai create crew` path, now copies AGENTS.md, CLAUDE.md and GEMINI.md; AGENTS.md documents the JSON layout - span helper no longer depends on OTEL_SDK_DISABLED being popped by an earlier test; thread-scope test stops its worker before leaving the mock - single import style in the shutdown test Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-16 02:07:57 -03:00
Lorenze Jay	993a96c4e0	feat(tracing): port trace events sessions to OSS (#7464) ... * feat(tracing): port enterprise event sessions to OSS * fix(tracing): address review findings and verify concurrent exports * fix(tracing): keep redactor ownership in enterprise integrations * test(tracing): isolate intentional failures from cleanup assertions	2026-09-15 13:09:40 -07:00
Melanie Hart BuehlerandVidit Ostwal	21678f8ac6	docs(rag): add xpu to embedding device options (#6808) ... * docs(rag): add xpu to embedding device options * address copilot review * docs(rag): sync Korean and Portuguese RagTool pages --------- Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-09-14 05:51:43 +00:00
Gamal OsamaandVidit Ostwal	c860613c7a	feat(embeddings): add openrouter as a supported embedding provider (#7127) ... * feat(embeddings): add openrouter provider type definitions * feat(embeddings): implement OpenRouterProvider * feat(embeddings): export openrouter provider package symbols * feat(embeddings): register openrouter in allowed embedding providers * feat(embeddings): register openrouter provider and overloads in factory * feat(tools): add openrouter embedding service support * test(embeddings): add comprehensive openrouter provider and factory tests * test(embeddings): add openrouter build test in embedding factory * test(embeddings): add openrouter model key alias and env tests * test(tools): add openrouter tests for embedding service * docs: add openrouter embedder configuration example * docs(ar): sync openrouter embedder translation * docs(ko): sync openrouter embedder translation * docs(pt-BR): sync openrouter embedder translation * feat(embeddings): allow model alias and None fields in OpenRouterProviderConfig * fix(tools): resolve EMBEDDINGS_OPENROUTER_API_KEY before OPENROUTER_API_KEY * test(tools): add regression tests for openrouter env var precedence and fallback * feat(embeddings): drop organization_id and resolve api_key via OPENROUTER_API_KEY only * fix(tools): use OPENROUTER_API_KEY in embedding service and update tests * docs: switch openrouter knowledge example to model_name and document OPENROUTER_API_KEY * fix(tools): default openrouter model to namespaced openai/text-embedding-3-small --------- Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-09-10 12:24:15 +05:30
Lorenze Jay	a8d330de00	[docs-freeze] docs: snapshot and changelog for v1.15.21 (#7363)	2026-09-09 22:54:07 +00:00
João MouraandClaude Opus 5	d729cade6b	fix(openai): surface gateway errors reported inside an HTTP 200 (#7342) ... * fix(openai): surface gateway errors reported inside an HTTP 200 OpenAI-compatible gateways commit `200 OK` as soon as the upstream provider accepts a request, so a later provider failure arrives in the body as an `error` object with no `choices`. That reached the SDK's parse helper and surfaced as `TypeError: 'NoneType' object is not iterable`, naming neither the provider, the status, nor the fact that a timeout happened. The four non-streaming paths now inspect the raw body before parsing and raise the exception the upstream code maps to, so a masked 504 is catchable exactly like an honest one. Streaming already had this guard inside the SDK. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(openai): teach the tool-cache fake about with_raw_response The provider now reads the raw body before parsing, so a client double that only implements `create` no longer satisfies it. Same shape as the fixes to the reasoning-effort retry and Snowflake doubles. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(tracing): reset the TraceCollectionListener singleton between tests TraceCollectionListener caches a TraceBatchManager on the class and `_initialized` short-circuits `__init__`, so batch state survives for the whole xdist worker. `test_nested_agent_executor_flow_does_not_finalize_parent_batch` left `trace_batch_id="debug-trace-batch"` behind, which moved every later trace POST from /tracing/ephemeral/batches to /tracing/batches/<id>/events. The recorded cassette then stopped matching, the agent retried, and the second call found the cassette consumed -- surfacing as ConnectionError in an unrelated test hundreds of tests later. Reproduced deterministically by running the leaking test followed by tests/tracing/test_trace_enable_disable.py::test_trace_calls_when_enabled_via_env; fails on a68b5e903 too, so this predates the gateway fix it was blocking. An autouse fixture now clears the cached instance after each test. Two canaries pin the invariant and fail without the fixture. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(tracing): drop the unwritable _listeners_setup canary Both review bots flagged that the canary read `_listeners_setup` off the class, where it is always False, so it could never fail. Correct, and the suggested fix does not work either: `BaseEventListener.__init__` calls `setup_listeners` (base_event_listener.py:16), which sets the flag on the instance (trace_listener.py:229), so reading it back through `TraceCollectionListener()` is always True. Neither read observes a leak, so the canary is deleted rather than replaced, with the reasoning recorded so it is not re-added. The same finding showed the fixture was resetting two class attributes that are never assigned at class level. Only dropping `_instance` is load-bearing, so the fixture is now one line. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(tracing): correct why the _listeners_setup canary is unwritable setup_listeners returns early when tracing is off and no override applies (trace_listener.py:213-220), assigning the flag at :229 only when it actually registers. Construction therefore does not always set it, as the previous note claimed: with tracing disabled the flag never even reaches the instance dict. The instance read reports ambient tracing state rather than isolation, which is a better reason not to assert on it than the one recorded before. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tests): clear trace batch state in place instead of dropping the singleton Dropping `TraceCollectionListener._instance` made the next construction re-run `setup_listeners`, re-registering its handlers on the event bus. That broke tests/telemetry/test_task_failure_instrumentation.py, which requires exactly one handler per event: the re-registered `on_task_failed` made two. Verified against a53ecc17f, where the same sequence passes -- the regression was mine. The leak that needed fixing was batch state, not registration, so the fixture now clears the manager's batch fields in place. Handler cleanup already belongs to `cleanup_event_handlers`, and `first_time_handler` keeps its reference to the same manager object. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tests): clear tracing context vars so the listener can re-register Bugbot flagged that keeping the singleton leaves `_listeners_setup` set, so after `cleanup_event_handlers` wipes the bus `setup_listeners` returns early (trace_listener.py:208) and tracing silently registers nothing for the rest of the worker. Confirmed: after a tracing-enabled run, re-running setup restores 0 of 119 handler entries. Dropping the singleton fixes that but previously broke test_task_failure_instrumentation. The real cause was a third leak: the `_tracing_enabled` context var stayed set, so the replacement listener still believed tracing was on and re-registered `on_task_failed` next to telemetry's. Clearing the context vars is what makes replacing the listener safe, so the fixture now does both, and a canary pins it (fails with `assert True is False` without the drop). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-09 15:12:57 -07:00
Vidit Ostwal	4ed4aba6cd	fix(cli): keep deploy push on the AMP create source (#7345) ... Push was choosing ZIP vs git from a local origin remote, so adding origin later rebuilt the last ZIP with no files. Prefer AMP zip_deployment from status, and fall back to the old origin heuristic when that field is missing.	2026-09-10 00:23:40 +05:30
4 people	b92e80be53	chore(tools): make the vision_tool more dynamic (#7350) ... * chore(tools): make the vision_tool more dynamic * tackle review comments * chore: update tool specifications * refactor(tools): simplify vision tool model selection --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: ViditOstwal <viditostwal@gmail.com> Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-09-09 22:18:53 +05:30
Vidit Ostwal	79befd0ce5	docs: clarify that tracing is managed separately from telemetry (#7311) ... Users who disable telemetry still need the tracing docs to understand first-run trace viewing and how the two settings relate.	2026-09-08 23:08:10 +05:30
oxy-giedriusandClaude Opus 5	fe62d04cdb	fix(oxylabs): report scrape failures instead of raising IndexError (#7044) ... * fix(oxylabs): report scrape failures instead of raising IndexError The oxylabs SDK logs HTTP errors and returns an empty response rather than raising, so the unchecked `response.results[0]` in every Oxylabs tool turned a rejected request into `IndexError: list index out of range`. Invalid credentials -- the most likely first-run mistake -- gave no indication of the cause. A result carrying a non-2xx `status_code` had the same problem one level down: the job ran, the page did not come back, and the tool returned its empty content as though the scrape had succeeded, handing the agent "[]". Both are now reported as a `ToolFailure` naming what went wrong, so the agent gets something it can act on and the framework records the call as failed: 401 Unauthorized 400 Bad Request - Parameter `parsing_instructions` can be used just with `parse` parameter set to `true`. Because the SDK keeps the cause only in its own log, the failing call is run with a handler attached to the `oxylabs` logger and the status, the API's explanation and timeouts are read back off it. `code` and `retryable` are set from the status, so 429 and 5xx are marked worth retrying. Nothing about the caller's logging configuration is changed; an application that has silenced the SDK still gets the generic failure. Content that is neither a string nor a dict is also serialized properly: `parsing_instructions` commonly yields a list, and the previous `str()` fallback produced a Python repr with single quotes instead of JSON. The client construction and response handling these four tools duplicated verbatim now live in a shared `OxylabsBaseTool`, following the existing `SerpApiBaseTool` pattern, so the handling above exists in one place. The generated tool specs change only by the new `locale` field, confirming the tools' public surface is otherwise untouched. Also add the `locale` option to the Google Search config, which the docs already documented but the config model silently dropped, and correct two copy-paste errors in the docs across all four locales. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(oxylabs): keep concurrent scrape diagnoses apart The error capture attached a fresh handler to the shared `oxylabs` logger for each scrape, so two scrapes in flight at once each saw both errors. `_diagnose` reads the first HTTP status it finds, so a timeout could be reported as the other request's 400 -- `retryable=False` on a failure that was worth retrying. One handler now serves every scrape and routes each record to the capture of the call that caused it via a `ContextVar`, which isolates threads and asyncio tasks alike. Serializing the captures would have fixed the cross-talk too, but at the cost of running every scrape one at a time. The handler stays attached once installed: it is inert outside a capture, and detaching it would race with concurrent scrapes. The regression test forces the interleaving -- one capture is held open while the other call logs -- and fails against the previous implementation. Also drive `config` through the public constructor in the tests instead of assigning `__dict__["config"]`, so they would catch `__init__` dropping a supplied config. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-08 12:42:48 +05:30
3 people	143e902178	docs: use organization UUIDs in the skill install reference (#7273) ... Organization names are not unique, so the documented `@org/name` form can resolve to the wrong organization and fail to find the skill. Document the `@org-uuid/name` form instead, and add a note pointing at `crewai org list` for the UUID. Applies to the agent-side registry refs too: they resolve through the same `/skills/:org/:name` endpoint and the same `~/.crewai/skills/{org}/{name}/` cache path, so leaving them as `@acme` would contradict the install command. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-09-04 13:26:07 -07:00
João Moura	a024115e4e	[docs-freeze] docs: snapshot and changelog for v1.15.20 (#7271)	2026-09-04 09:42:07 -03:00
João Moura	04e2efbdab	[docs-freeze] docs: snapshot and changelog for v1.15.19 (#7266)	2026-09-04 08:28:16 -03:00
Fang KaiqiandVidit Ostwal	b608a3595c	docs: remove CodeInterpreterTool from AI/ML overview examples (#7100) ... Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-09-02 10:31:18 +05:30
Fang KaiqiandVidit Ostwal	f5db5a1788	docs: point prompt-template link at its current path (#7101) ... Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-09-02 10:21:40 +05:30
Vidit OstwalandLorenze Jay	818f2624e8	[OSS-149] Accept 1/yes/on on telemetry disable flags (#7185) ... * fix(telemetry): accept 1/yes/on on disable flags CREWAI_DISABLE_TELEMETRY=1 was ignored because the gate only matched true, so telemetry stayed on with no warning. * fix(telemetry): warn once on unrecognized disable values Stop repeating the same invalid-flag warning on every telemetry check, and drop the undocumented CREWAI_DISABLE_TRACKING alias from docs. --------- Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>	2026-09-01 11:41:20 -07:00
Ran ShemtovandLorenze Jay	a35fbc864d	docs: update channels guide to current copilotkit channels api (#7016) ... * docs: update channels guide to current copilotkit channels api * docs: translate channels and frontend overview guides to ar, ko, pt-BR --------- Co-authored-by: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>	2026-08-31 15:47:58 +00:00
chenshiyangandVidit Ostwal	265697b6f8	docs: refresh retired Gemini model ids (#7003) ... Co-authored-by: Vidit Ostwal <110953813+Vidit-Ostwal@users.noreply.github.com>	2026-08-31 10:43:31 -03:00
João MouraandClaude Opus 5	1f6e327b3c	feat(events): report machine size as a coarse band, not a core count (#7117) ... * feat(events): report machine size as a coarse band, not a core count `runtime_context` says where a process runs but carries no capacity axis, and its largest bucket is a catch-all: a gunicorn worker on a VM and `python main.py > out.log` on a MacBook both report `non_interactive`. Docker Desktop on a laptop reports `container` via /.dockerenv, and a Remote-SSH shell on a server reports `vscode_terminal`. So "server or laptop" is not answerable from it today. Adds `cpu_band` to the common span attributes, so it rides every span the way `runtime_context` does rather than sitting on `Crew Created` alone - which would answer nothing for Flow-only, CLI-only or standalone-agent runs. Six bands, powers of two, top one open-ended: 1-2, 3-4, 5-8, 9-16, 17-32, 33+. Open-ended because the exact count is the fingerprint - the observed fleet maximum is 512, and a span reporting 512 identifies one machine. The vocabulary is closed and asserted, like KNOWN_CODING_AGENTS and KNOWN_RUNTIME_CONTEXTS. The share_crew-gated exact `cpus` attribute and the four platform* attributes are untouched. That gating was a deliberate 2024 classification of machine fingerprint as shareable content (44e38b1d5), and this does not reverse it: a band is a range, the gated attribute remains the precise value. Documents a trap in the docstring rather than leaving it to be rediscovered: os.cpu_count() reports HOST cores, not the cgroup quota, so a 1-vCPU pod on a 96-core node lands in 33+. Right for "what kind of machine", wrong for "what did this run get" - os.process_cpu_count() gives the latter but needs 3.13, above this package's floor. Docs updated in en/ar/ko/pt-BR, in the default-on Execution Environment row, stating explicitly that the band is a range and the exact count stays opt-in. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(telemetry): say where the cpu band comes from The Execution Environment row ended "Detection reads only whether known environment variables are set, never their values". True for the assistant and runtime-context fields, and wrong for the band this PR adds: detect_cpu_band() reads os.cpu_count() (runtime_env.py:306) and touches no environment variable. In a privacy disclosure table that is the kind of inaccuracy worth a line. Names the source explicitly and scopes the env-var sentence to the two fields it actually describes. All four locales at parity. pt-BR also takes the reviewer's wording fix: "um de uma lista fixa" -> "um valor de uma lista fixa", and the missing comma before o `project_id`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-28 08:50:10 -07:00
Lorenze Jay	4bc5d29242	[docs-freeze] docs: snapshot and changelog for v1.15.18 (#7138)	2026-08-27 18:07:05 +00:00
Lorenze JayandCursor	f90d37b4ac	feat(flow): promote conversational flows to stable (#7107) ... Move the canonical API into crewai.flow while preserving experimental imports and declarative references through compatibility aliases. Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-27 23:06:57 +05:30
Vidit Ostwal	56e0e85a81	[OSS-115] Persist custom conversational replies after fallback append (#7026) ... * fix(flows): persist custom conversational replies after fallback append Custom @listen routes that only return a public string were appended after kickoff, so @persist snapshots missed the assistant turn. Snapshot again from the same persist path once the fallback writes state.messages. * test(flows): cover @persist restore of custom conversational replies Add regression coverage for custom @listen returns across fresh Flow instances, no double-append on built-in converse, and a single user/assistant message-added event. * docs: note that public listen returns persist as assistant replies	2026-08-26 09:41:28 -07:00
3 people	4e0b2e2b15	fix(events): record task failures as failures, not as successes (#7073) ... * fix(telemetry): record task failures as failures, not as successes close_span() sets StatusCode.OK unconditionally, and TaskFailedEvent was routed to Telemetry.task_ended, which calls it. Every failed task was therefore exported as OK, which is why error_count downstream is not merely low but exactly zero: 240.0M task executions across 13 months in crew_task_executions_daily_target, error_count = 0 in every one of them. The same line had a second defect. The span was only ended when source.agent.crew was present, so a task failing without one was popped from the span map and then never closed - never ended, never exported, invisible rather than mislabelled. task_failed takes no crew (it reads nothing off one), so that condition disappears rather than being widened. Only the exception class name is recorded, never the message, which routinely contains prompts, model output, file paths and credentials. close_span_with_error drops any value failing str.isidentifier(), so a message cannot be recorded even if one is passed by mistake. This is the task half of closed PR #6781, re-cut onto main as that PR asked for. The crew half is deliberately left out: crew_execution_span() returns None unless share_crew=True, so crew._execution_span is None for nearly every user and a crew-failure handler would exit immediately for the default population. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * fix(telemetry): take the exception class for error_type, not a free-form string cursor and CodeRabbit both flagged the sanitization, and they were right: the package already had a stronger convention and this change had not used it. Telemetry._safe_error_type takes the exception *class*, and its docstring says why in as many words - "a single-word message such as 'secret_token' is itself a valid identifier", so filtering a string with isidentifier() is not enough. The ported code predates that helper and reinvented the weaker check. TaskFailedEvent.error_type is now type[BaseException] | None, so pydantic itself rejects a message before any of our code runs, and task_failed routes it through _safe_error_type. The identifier check in close_span_with_error stays as the second gate on the derived name, which is the role _safe_error_type's docstring already describes. Also adds producer-level tests, which CodeRabbit correctly identified as missing: every earlier test constructed TaskFailedEvent directly, so a regression in the two emit sites this change touches in task.py would have passed the whole suite. The sync and async producers are driven through Task._execute_core and Task._aexecute_core with a distinctive exception class, and each patches a different agent method (execute_task vs aexecute_task), which is why they can regress independently. Verified by dropping error_type from both producers: all three new tests fail, and pass again when restored. Removes an unused `import os` left behind when the fixture was rewritten. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * test(telemetry): capture producer failures at the emit boundary, not via the bus The producer tests subscribed a handler to crewai_event_bus and asserted on what it received. That passed this file in isolation and every randomized local run, then failed in CI inside a 621-test shard with zero events captured: FAILED tests/telemetry/test_task_failure_instrumentation.py:: test_sync_producer_puts_the_exception_class_on_the_event assert 0 == 1 + where 0 = len([]) task_failed is an "ending" event, and with an empty scope stack - there is no real kickoff in these tests - dispatch is conditional on event-context state that other tests in the same worker process can leave behind. Subscribing made the assertion depend on the bus choosing to dispatch, which is not what these tests are about: they are about what the producer in task.py constructs. Patching crewai_event_bus.emit records the event unconditionally at the point the producer hands it over, with no dispatch involved. Both producers ignore emit's return value, so returning None is faithful. Containment re-verified after the change: dropping error_type from both producers fails exactly these three tests and nothing else. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * fix(events): keep TaskFailedEvent JSON-serializable with a class-valued error_type error_type holds an exception class, which is not a JSON type, so model_dump(mode="json") raised PydanticSerializationError for the whole event - not just that field. Two real consumers depend on it: the checkpoint listener dumps every event through EventRecord, and the tracing listener JSON-POSTs events to AMP. A single task failure therefore took out checkpointing. field_serializer with when_used="json" returns the class name. The "json" scope is load-bearing: event_listener hands the live class to Telemetry.task_failed, which needs it for _safe_error_type, so python-mode dumps must keep the class. The annotation is a module-level _ExceptionClass alias rather than an inline type[BaseException], because TaskFailedEvent declares a field named `type` which shadows the builtin for the rest of the class body - inline, it raises TypeError at import ("task_failed"[BaseException]) and mypy rejects it as "Variable ... is not valid as a type". Quoting satisfies neither tool: ruff flags UP037 and mypy still resolves it in the class scope. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RfV2uMqWRcdfufMvtdCVoN * fix(events): let a dumped error_type restore, instead of degrading the event The serializer added in the previous commit stopped model_dump(mode="json") from raising, but nothing accepted the class-name string back. _resolve_event (state/event_record.py:32-35) wraps cls.model_validate in a bare except and falls back to BaseEvent, so restoring a checkpoint after a task failure silently dropped the whole event -- including `error`, a plain string that would otherwise have survived. Traded a loud failure for a quiet one. Measured before: dumped error_type='ValueError' and error='boom', restored as BaseEvent with neither attribute. After: restores as TaskFailedEvent with error='boom' and error_type is ValueError. A BeforeValidator resolves a name against real exception classes only -- builtins first, then a walk of BaseException.__subclasses__(). So this does not reopen the hole the class-typed field closes: "secret_token" resolves to nothing, is returned unchanged, and is rejected by the field's own type. Asserted for secret_token, sk_live_1234, dict and os. A name whose class is not imported in this process still degrades, which is deliberate: synthesising a class from an arbitrary string is the injection risk this field exists to avoid. 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-25 14:30:46 +05:30
Lorenze JayandCursor	a9cb0bdf02	Lorenze/deprecate/answer from history (#7105) ... * feat(flows): enhance conversational flow documentation and APIs - Updated the description to clarify the use of `handle_turn` and structured streaming in multi-turn chat applications. - Added a warning about the experimental nature of the conversational features. - Improved the overview section to include structured streaming and refined the explanation of session handling. - Enhanced the API documentation for `handle_turn`, `stream_turn`, and `chat` methods, emphasizing their roles in conversational flows. - Clarified the turn lifecycle and the handling of user messages within the flow. - Updated examples to reflect changes in message handling and session tracing. - Ensured consistency across language versions in the documentation. * feat(flow): deprecate answer_from_history route Guide conversational flows toward the existing converse route while preserving compatibility warnings and schema metadata. Co-authored-by: Cursor <cursoragent@cursor.com> * stacklevel=3 raising it higher --------- Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-25 11:01:22 +05:30
3 people	9652af6ae0	fix(agents): keep message roles when Agent.kickoff gets a conversation (#7065) ... * fix(agents): keep message roles when Agent.kickoff gets a conversation `Agent.kickoff` accepts `str | list[LLMMessage]`, but `_prepare_kickoff` joined every message's content into one string. Measured with a recording LLM, a three-turn conversation reached the provider as two messages: system | You are Support... user | Current Task: my order id is 42\nthanks, checking\nwhere is it? So the agent's own previous reply was presented as something the user said, and the model could not tell who said what. `LiteAgent.kickoff` already did this correctly, which is why the same list gave four messages with roles intact there. The last message is now this turn's request and the ones before it travel as `inputs["history"]` -- the way `inputs["files"]` already does -- which both executors splice in after the system prompt and before the user prompt. Memory recall still runs over the whole conversation text, not just the last turn. A plain string and a single-message list are byte-identical to before, which is what every existing caller passes. Also widens `LiteAgentExecutionStartedEvent.messages` from `list[dict[str, str]]` to `list[LLMMessage]`: it raised a ValidationError for a message whose content was `None` or a content-part list, both of which are valid `LLMMessage` shapes that `Agent.kickoff` already accepts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(agents): carry history without a system prompt, tool calls, or dup files Three review findings on the message-role work, all real. History was spliced only in the branch that builds a system prompt. With `use_system_prompt=False` or a custom template there is one combined prompt, so history went nowhere and only the last turn reached the model -- worse than the flattening this PR replaced, which at least included the text. Both executors now splice in either branch, via one `_append_history` helper each. Filtering on truthy content dropped an assistant turn that only requests tool calls, leaving a `tool` message with no preceding `tool_calls` message -- a sequence providers reject. A message now counts when it has content, tool calls, or a tool_call_id. And `files` were unioned from every message onto the current request while history messages kept their own, so prior attachments were sent twice. Only the current request's attachments travel in `inputs["files"]` now. Found by Cursor and CodeRabbit on #7065. * fix(agents): treat an attachment as message payload _carries_payload counted text, tool calls and tool results, but not files. A final message whose only payload was an attachment was filtered out, so the previous message became this turn request and the attachment never reached inputs["files"]. Found independently by Cursor and CodeRabbit on #7065. * fix(agents): promote the last user message, not the last message build_agent_context() appends an agent private thread after the current user turn, so on a later turn the trailing message is an assistant scratch. That scratch became Current Task while the real question was demoted to history -- reproduced: the request came back as "internal note: checked warehouse". The request is now the last user message, with everything else kept as history in order; with no user message the last one stands in, which is what a single-message caller has always got. Documented on kickoff and kickoff_async. The old cross-check against LiteAgent only compared roles on a fixture already ending in a user message, so it could not catch this. It now asserts what holds for both -- nothing dropped, nothing duplicated -- since Agent has a task slot in its prompt and LiteAgent does not. Reported by Vidit-Ostwal on #7065. * test(agents): cover history placement on the deprecated executor too `CrewAgentExecutor` carries its own `_setup_messages`, and `Agent.kickoff` builds an `AgentExecutor` unconditionally, so nothing reached the twin's two `_append_history` sites. This drives that executor directly with the real `SystemPromptResult` / `StandardPromptResult` shapes, so both its branches are pinned. Verified by mutation: removing either `_append_history` call in either executor now fails the matching test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VwxiogL9mQg9q8cx4qLfYJ * fix(agents): keep turns that follow the request after it `_prepare_kickoff` packed every non-request message into one `history` list, and both executors spliced that list before the current user prompt. A conversation ending on a tool result therefore reached the provider as `assistant tool_calls -> tool -> user`, hoisting the tool pair above the question it answers. `LiteAgent` sends the same list as `user -> assistant -> tool`. Splits the carried messages at the request instead: what came before stays `history`, what came after travels as `trailing` and is appended after the user prompt. Promoting the last user message to `{input}` is unchanged. `test_a_tool_call_sequence_survives` missed this because it ends on a follow-up user line, so the tool pair was already before the request. Reported by lorenzejay, who also confirmed gpt-4o-mini and gpt-5.6-sol accept the reordered payload -- an order bug, not a provider 400. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VwxiogL9mQg9q8cx4qLfYJ * test(agents): assert the ordering through kickoff_async too `kickoff_async` shares `_prepare_kickoff`, and the async executor entry points reach the same `_setup_messages`, but sharing a code path is not the same as covering it. Pins the tool-result ordering through the async path, and lifts the tool conversation to a module-level fixture so the sync and async assertions cannot drift. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VwxiogL9mQg9q8cx4qLfYJ * docs(agents): state where a kickoff conversation's turns land `concepts/agents.mdx` documents the multi-message form but not which message becomes the request or what happens to the turns around it -- the contract this branch changed. Corrects the `kickoff` / `kickoff_async` docstrings to match. en and ko only: the ar and pt-BR pages do not carry the "Multiple Messages" section at all, which is a pre-existing translation gap rather than one this change introduces. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VwxiogL9mQg9q8cx4qLfYJ * feat(flow): let a declarative agent action receive the conversation (#7066) * feat(flow): let a declarative agent action receive the conversation A chat handler could only hand its agent a single string, so a declarative conversational flow's `agent` action never saw prior turns. Both ends blocked it: `AgentDefinition.input` was `str` with a validator rejecting anything else, and `AgentAction.run` raised "agent input must render to a string" once a CEL template rendered to a list. `input` now takes a string or a list of messages, and the action normalizes rather than rejecting. A whole-string `${...}` template keeps its evaluated type, so `state.messages.map(m, {'role': m.role, 'content': m.content})` renders the exact shape the agent wants -- no new CEL function needed. Serialized messages carry `name: None` and `metadata` that the agent event schema rejects, and `message_to_llm_dict` only drops `None` for a model input, not the plain dicts a CEL render produces. The normalizer drops them, keeping `content: None` since that is a valid message shape. Declarative crews are unaffected: they use `CrewAgentDefinition`, which has no `input` field at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(flows): pin content=None survival through agent input normalization A filter-all-None change would silently drop the assistant turn that only requests tool calls, and no test covered that key. Found by CodeRabbit on #7066. * test(flows): cover the agent action through kickoff, not the helper The existing tests called _normalize_agent_input directly, so nothing pinned that Expression.render_template -> normalization -> Agent.kickoff_async keeps a message list intact. Removing the normalization call now fails this test. Found by CodeRabbit on #7066. --------- 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: Lorenze Jay <63378463+lorenzejay@users.noreply.github.com>	2026-08-24 21:09:36 +00:00
João MouraandClaude Opus 5	500ebc7a68	feat(flow): let a declaration name the router's response format (#7063) ... * feat(flow): let a declaration name the router's response format `conversational.router.response_format` was typed `Any` and dropped with a warning, because `_router_response_format` hands its value straight to `llm.call(response_format=...)`, which needs a real class. So the router always used its synthesized fallback: `intent: str` with the route labels only in a field description. The field now takes the same `{"python": "module.path.Class"}` shape a crew agent's `response_format` uses, resolved through the same `_resolve_model_class`. That brings the project-root containment with it -- a declaration cannot reach outside the project to import code -- and gives the router a `Literal[...]` of the real route labels instead of a bare string. The DSL projection now emits that shape too, so a live class on a Python flow round-trips as `{"python": ...}` rather than an opaque `{"ref": ...}` that nothing could reload. A bare `module:qualname` ref is now a load-time validation error instead of being silently discarded; the test that pinned the old drop-with-warning behavior is updated to assert that. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(flow): do not project a response format that cannot be reloaded `_python_reference` emitted a dotted path for any class, including two that cannot be imported back: a non-Pydantic class, and one defined inside a function, whose `__qualname__` carries `<locals>`. The definition then held a ref that only failed when something tried to resolve it. Both are dropped at projection time with a warning naming why, so a reload falls back to the synthesized response format. The live class still drives the running flow; only the projection omits it. Found by CodeRabbit on #7063. * test(flows): assert the response_format omission warnings The projection tests only checked for None, so removing the warning that tells an author their response_format was dropped would still pass. Found by CodeRabbit on #7063. * fix(flows): only project a response_format ref that imports back The check rejected <locals> classes but still emitted a path for a nested one. The loader splits a ref on its last dot, so module.Outer.Route resolves module.Outer as a module that does not exist - proven: reload raised JSONProjectError. A create_model() class held only in a local is unreachable the same way. Projection now confirms module.qualname resolves back to the class, against the already-imported module so it never triggers an import. Found by CodeRabbit on #7063. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-24 13:53:15 -07:00
Lorenze Jay	090633737c	feat(flows): enhance conversational flow documentation and APIs (#7104) ... - Updated the description to clarify the use of `handle_turn` and structured streaming in multi-turn chat applications. - Added a warning about the experimental nature of the conversational features. - Improved the overview section to include structured streaming and refined the explanation of session handling. - Enhanced the API documentation for `handle_turn`, `stream_turn`, and `chat` methods, emphasizing their roles in conversational flows. - Clarified the turn lifecycle and the handling of user messages within the flow. - Updated examples to reflect changes in message handling and session tracing. - Ensured consistency across language versions in the documentation.	2026-08-24 11:26:31 -07:00
3 people	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