Files
crewAI/lib/cli/tests
João Moura 6e1fa8cf2a feat(tracing): record the last traced run for crewai eval instead of printing it (#7648)
* feat(tracing): record the last traced run for crewai eval instead of printing it

After a traced run, crewAI printed a panel with the execution id and a
viewer link. The id is internal, and the panel exposed it for no purpose a
user has. Nothing is printed now. Instead, once the run's spans have
reached Wharf, crewAI writes `.crewai/last_run.json` in the project: the
execution id, when the run started and ended, whether it was traced
anonymously or under an account, and the AMP base url. `crewai eval` reads
it back, so the user evaluates their last run without pasting anything.

GrantSpanExporter.record_export replaces show_trace_summary at the two
finish points (an authenticated run's shutdown, an anonymous run's share).
Only a run whose every export succeeded is recorded — a partial export
would name a run the grader could not read whole. Recording is silent in
the TUI and under message suppression too, off under the test suite, and
inert inside a deployment, where the platform binds the execution before
crewAI's own tracing starts. The record is written atomically and a write
failure never fails the run.

The crew, flow and json_crew scaffolds now ignore `.crewai/` like the
declarative flow scaffold already did.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(tracing): never record a truncated ephemeral run; resolve the record path inside the guard; pin the window and the once

- An ephemeral buffer that dropped spans at its cap still uploaded the rest
  and recorded the run. The grader could not read that run whole, so it is
  no longer recorded (the upload still happens). Test added.
- last_run_path() ran before the try in record_last_run; a cwd that
  vanished mid-run would have raised out of a function documented never to
  raise. It is inside now, with the same debug log and None.
- Tests: the "recorded once" check counted an unchanged mtime, which proves
  nothing on a coarse filesystem — it now counts calls to record_last_run;
  the first-start/last-end fold across export batches had no value test —
  batches now arrive out of order and the ISO window is asserted.
- Docs: the conversational-flows comment said "one trace link" for output
  that no longer exists; tracing.mdx now names .crewai/last_run.json, what
  it holds, who reads it, and when it is not written. en, ar, ko, pt-BR.

85 passed (test_session_trace_export + test_last_run); ruff and mypy clean.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(tracing): a temporary file of its own per writer; the docs name deployments

- record_last_run wrote every record through one `.tmp` name, so two crews
  finishing together in one project could replace each other's temporary
  file and one record was lost. Each write now goes through
  tempfile.mkstemp in the same directory, then os.replace; a failed write
  removes its own temporary file. Tests: two writers use two names and
  leave only last_run.json; a failed replace leaves nothing behind.
- tracing.mdx (en, ar, ko, pt-BR): nothing is recorded inside a
  deployment, where the platform owns the trace.

87 passed (test_last_run + test_session_trace_export); ruff and mypy clean.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(tracing): the run that finished last stays recorded, whichever writer comes last

Two crews finishing together in one project: the older run's writer could
reach the file after the newer one and leave the older run as "the last".
record_last_run now compares finished_at (recorded_at when absent) with
the record already there and keeps the later-finished run; the same run
recorded again (a refreshed grant) and a record without a comparable time
never block the run just finished. No lock file: the file is a convenience
pointer and the compare closes the ordering, leaving a microsecond window
between read and replace that two runs finishing in the same instant
could hit — either is then a fair "last run".

Test: the older writer replaces after the newer one; the newer stays.
88 passed.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(tracing): a same-millisecond tie keeps the record already there; nothing is recorded inside a deployment

- The times in the record are stored to the millisecond; two runs finishing
  in the same millisecond compared equal and the later writer won, which
  could leave the older run recorded. A tie now keeps what is there. No
  finer order is worth a field in the file.
- recording_enabled() is false when the platform's integration token is
  present: a deployment normally never reaches this code (the host binds
  the trace before crewAI would start its own), but a container that did
  not would have written a file the platform never reads, against what the
  docs promise. Test added.

89 passed; ruff and mypy clean.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(tracing): only a run that provably finished later holds the record

My previous commit compared `finished_at` and fell back to `recorded_at`,
which broke two existing tests on CI: two records written in the same
millisecond with no completion time compared equal, so the second write was
dropped and the older run stayed. Locally the two writes happened to land in
different milliseconds, so the suite passed — a timing-dependent bug, not a
CI quirk.

The rule is now narrow: a write stands unless the record already there is a
DIFFERENT run with a later `finished_at`. No completion time on either side,
the same run recorded again, or a tie to the millisecond all leave the write
to stand, so "the last run recorded" stays what a reader gets. The case the
rule exists for is unchanged: the older-finished writer arriving last does
not replace the newer one.

485 passed in lib/crewai/tests/telemetry (test_last_run run five times for
timing); ruff and mypy clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(tracing): serialise the write across processes; drop the platform-token guard, which was not a deployment test

- Reading the record, deciding and replacing it are now one step, held
  under a lock file beside the record, so a writer can no longer decide
  against a record another process has already replaced. Where the platform
  has no flock the write goes ahead unserialised: the record is a
  convenience pointer for `crewai eval`, never worth failing a run over.
  The regression drives three writers at once and fails without the lock.
- The deployment guard I added yesterday read
  CREWAI_PLATFORM_INTEGRATION_TOKEN, which is not a deployment marker:
  `crewai create crew` writes that token into a project's own .env for
  platform tools, and crew_base loads it, so the guard would have stopped
  recording for every developer who uses them. It is also unnecessary — a
  deployment kicks off with tracing off, so crewAI never builds the
  exporter and never reaches this module. Guard removed, with a test that
  a project carrying that token is still recorded.
- The module docstring claimed the platform "binds the execution before
  crewAI would start its own tracing". It does not; it sets tracing off at
  kickoff. Docstring and the four tracing docs now say the real reason.

487 passed in lib/crewai/tests/telemetry; ruff and mypy clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(tracing): a refused lock still records the run; the platform-token test exercises the real guard

Two Cursor findings on the locking commit.

- If flock itself failed — some network mounts refuse it — the OSError
  escaped _exclusive, the outer handler deleted the temporary file and
  record_last_run returned None, so the run was not recorded at all.
  A refused lock is now logged and the write goes ahead unserialised,
  matching what already happened when the lock file could not be opened
  or flock does not exist. Unserialised beats not recorded.
- test_a_project_using_platform_tools_is_still_recorded used the `project`
  fixture, which stubs recording_enabled — the very thing under test — so
  the regression it guards could have come back green. It now stubs only
  project_dir and asserts the real guard.

13 in test_last_run, 489 across lib/crewai/tests/telemetry.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-21 17:28:25 +00:00
..