Collision-resistant gRPC worker request IDs with deterministic local sequencing

[davidahmann]

Problem observed

The gRPC worker runtime generated request IDs from a local incrementing counter only. That sequence is deterministic per process but collision-prone across runtime instances, which can degrade request/result correlation when multiple workers emit overlapping IDs. Operationally, this makes distributed traces and support debugging less reliable because identical request IDs can represent different calls.

Why it matters operationally

Runtime-level correlation identifiers are foundational for deterministic debugging in multi-agent and multi-worker deployments. If IDs can collide across instances, replay and incident analysis can attribute responses to the wrong request lineage. As deployment scale increases, this becomes a recurring reliability issue for logs, telemetry joins, and support workflows that depend on globally unique request correlation.

Minimal repro

uv run --project python pytest python/packages/autogen-ext/tests/test_worker_runtime.py -k request_ids_are_collision_resistant_per_runtime
python - <<'PY'
print('two runtimes with local counter both produce "1", "2" without prefixing')
PY

Fix approach

The change introduces a per-runtime UUID prefix and combines it with the existing monotonic sequence. This preserves deterministic local ordering while adding collision resistance across runtime instances. Scope is intentionally narrow: request ID generation contract only, no protocol schema changes. A focused regression test validates that IDs share a stable runtime prefix and retain sequence ordering (1, 2) within the same runtime.

Validation evidence

• Targeted test test_request_ids_are_collision_resistant_per_runtime passed.
• Existing request lifecycle behavior remains unchanged except identifier format.
• Prefix+sequence mapping keeps deterministic intra-runtime ordering.

Open follow-up question for maintainers

Should this request ID format be documented as a stable external contract, or treated as an internal implementation detail subject to change?

This contribution was informed by patterns from Wrkr. Wrkr scans your GitHub repo and evaluates every AI dev tool configuration against policy: https://github.com/Clyra-AI/wrkr