core/core-agent-ide
8
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
core-agent-ide/codex-rs/app-server-test-client/Cargo.toml

26 lines
763 B
TOML
Raw Normal View History

feat: add app-server-test-client crate for internal use (#5391) For app-server development it's been helpful to be able to trigger some test flows end-to-end and print the JSON-RPC messages sent between client and server.
2025-11-14 12:39:58 -08:00
[package]
name = "codex-app-server-test-client"
chore: add cargo-deny configuration (#7119) - add GitHub workflow running cargo-deny on push/PR - document cargo-deny allowlist with workspace-dep notes and advisory ignores - align workspace crates to inherit version/edition/license for consistent checks
2025-11-24 12:22:18 -08:00
version.workspace = true
edition.workspace = true
license.workspace = true
feat: add app-server-test-client crate for internal use (#5391) For app-server development it's been helpful to be able to trigger some test flows end-to-end and print the JSON-RPC messages sent between client and server.
2025-11-14 12:39:58 -08:00
[lints]
workspace = true
[dependencies]
anyhow = { workspace = true }
clap = { workspace = true, features = ["derive", "env"] }
codex-app-server-protocol = { workspace = true }
feat(app-server-test-client): OTEL setup for tracing (#13493) ### Overview This PR: - Updates `app-server-test-client` to load OTEL settings from `$CODEX_HOME/config.toml` and initializes its own OTEL provider. - Add real client root spans to app-server test client traces. This updates `codex-app-server-test-client` so its Datadog traces reflect the full client-driven flow instead of a set of server spans stitched together under a synthetic parent. Before this change, the test client generated a fake `traceparent` once and reused it for every JSON-RPC request. That kept the requests in one trace, but there was no real client span at the top, so Datadog ended up showing the sequence in a slightly misleading way, where all RPCs were anchored under `initialize`. Now the test client: - loads OTEL settings from the normal Codex config path, including `$CODEX_HOME/config.toml` and existing --config overrides - initializes tracing the same way other Codex binaries do when trace export is enabled - creates a real client root span for each scripted command - creates per-request client spans for JSON-RPC methods like `initialize`, `thread/start`, and `turn/start` - injects W3C trace context from the current client span into request.trace instead of reusing a fabricated carrier This gives us a cleaner trace shape in Datadog: - one trace URL for the whole scripted flow - a visible client root span - proper client/server parent-child relationships for each app-server request
2026-03-04 13:30:09 -08:00
codex-core = { workspace = true }
codex-otel = { workspace = true }
feat: add app-server-test-client crate for internal use (#5391) For app-server development it's been helpful to be able to trigger some test flows end-to-end and print the JSON-RPC messages sent between client and server.
2025-11-14 12:39:58 -08:00
codex-protocol = { workspace = true }
feat(app-server-test-client): OTEL setup for tracing (#13493) ### Overview This PR: - Updates `app-server-test-client` to load OTEL settings from `$CODEX_HOME/config.toml` and initializes its own OTEL provider. - Add real client root spans to app-server test client traces. This updates `codex-app-server-test-client` so its Datadog traces reflect the full client-driven flow instead of a set of server spans stitched together under a synthetic parent. Before this change, the test client generated a fake `traceparent` once and reused it for every JSON-RPC request. That kept the requests in one trace, but there was no real client span at the top, so Datadog ended up showing the sequence in a slightly misleading way, where all RPCs were anchored under `initialize`. Now the test client: - loads OTEL settings from the normal Codex config path, including `$CODEX_HOME/config.toml` and existing --config overrides - initializes tracing the same way other Codex binaries do when trace export is enabled - creates a real client root span for each scripted command - creates per-request client spans for JSON-RPC methods like `initialize`, `thread/start`, and `turn/start` - injects W3C trace context from the current client span into request.trace instead of reusing a fabricated carrier This gives us a cleaner trace shape in Datadog: - one trace URL for the whole scripted flow - a visible client root span - proper client/server parent-child relationships for each app-server request
2026-03-04 13:30:09 -08:00
codex-utils-cli = { workspace = true }
feat: add app-server-test-client crate for internal use (#5391) For app-server development it's been helpful to be able to trigger some test flows end-to-end and print the JSON-RPC messages sent between client and server.
2025-11-14 12:39:58 -08:00
serde = { workspace = true, features = ["derive"] }
serde_json = { workspace = true }
feat(app-server-test-client): OTEL setup for tracing (#13493) ### Overview This PR: - Updates `app-server-test-client` to load OTEL settings from `$CODEX_HOME/config.toml` and initializes its own OTEL provider. - Add real client root spans to app-server test client traces. This updates `codex-app-server-test-client` so its Datadog traces reflect the full client-driven flow instead of a set of server spans stitched together under a synthetic parent. Before this change, the test client generated a fake `traceparent` once and reused it for every JSON-RPC request. That kept the requests in one trace, but there was no real client span at the top, so Datadog ended up showing the sequence in a slightly misleading way, where all RPCs were anchored under `initialize`. Now the test client: - loads OTEL settings from the normal Codex config path, including `$CODEX_HOME/config.toml` and existing --config overrides - initializes tracing the same way other Codex binaries do when trace export is enabled - creates a real client root span for each scripted command - creates per-request client spans for JSON-RPC methods like `initialize`, `thread/start`, and `turn/start` - injects W3C trace context from the current client span into request.trace instead of reusing a fabricated carrier This gives us a cleaner trace shape in Datadog: - one trace URL for the whole scripted flow - a visible client root span - proper client/server parent-child relationships for each app-server request
2026-03-04 13:30:09 -08:00
tokio = { workspace = true, features = ["rt"] }
tracing = { workspace = true }
tracing-subscriber = { workspace = true }
app-server-test-client websocket client and thread tools (#11755) - add websocket endpoint mode with default ws://127.0.0.1:4222 while keeping stdio codex-bin path compatibility - add thread-resume (follow stream) and thread-list commands for manual thread lifecycle testing - quickstart docs
2026-02-13 09:34:35 -08:00
tungstenite = { workspace = true }
url = { workspace = true }
feat: add app-server-test-client crate for internal use (#5391) For app-server development it's been helpful to be able to trigger some test flows end-to-end and print the JSON-RPC messages sent between client and server.
2025-11-14 12:39:58 -08:00
uuid = { workspace = true, features = ["v4"] }
Reference in a new issue Copy permalink