GeezerVison

P3 sgp_evals_interceptor.py - activities of a child workflow get no header (memo is not inherited and their workflow id is not the task id), so their spans stay unstamped even when trace_id is the task id.
P3 worker.py:278 - no test pins SGPEvalsInterceptor in the worker's interceptor list, so dropping it keeps the suite green.

Refuted: continue-as-new keeps the memo (real dev-server run stamps the post-CAN run), ContextInterceptor headers coexist with this one in either order, and task_metadata does reach the agent inside params.task, so the event/send pop never drops a live eval task.

P3 sgp_evals_interceptor.py - activities of a child workflow get no header
P3 worker.py:278 - no test pins SGPEvalsInterceptor in the worker's interceptor list

Both closed. Child workflows now inherit the ids and the task id (a789175), and test_worker_runs_with_the_interceptor_ahead_of_agent_interceptors pins the worker's interceptor list.

@mohammadatallah-scale I re-checked a789175/8a170c1. The child-workflow memo + task-id header fix and skipping pins with no SGP processor both look right, and neither runs without eval ids. Two things before merge:

• CI is red on 040_other_sdks and 020_state_machine (and 010_agent_chat was cancelled), which all passed on 848212a. The assertions are live-model ones ("Did not use tool requests", "Did not find an agent message"), the image pulls retried, and 040_other_sdks isn't Temporal, so this looks like flake rather than this change. Worth a rerun before merging.
• Greptile's new P1 on sgp_evals.py:96 is real but narrow: it needs the SGP processor to be created after a span starts and that task to gain eval ids later. Fine to leave as a named gap; my approval stands.

CI is red on 040_other_sdks and 020_state_machine (and 010_agent_chat was cancelled) ... Worth a rerun before merging.
Greptile's new P1 on sgp_evals.py:96 is real but narrow ... Fine to leave as a named gap

@andrewvo-scale The P1 is fixed rather than left open (b45d3b3): an unpinned span now only gets ids its task had at its start. On CI, the same three tutorials fail or cancel the same way on two unrelated branches (jerome/worker-startup-compatibility, dm/retry-pydantic-ai-pypi-fetches), so it is the live-model flake. The push re-runs them.

040_other_sdks isn't Temporal, so this looks like flake rather than this change. Worth a rerun before merging.

@andrewvo-scale Correction to my earlier reply: it is not a flake, and not this change either. openai-websearch-mcp pins mcp==1.13.1, which imports pydantic._internal._typing_extra.eval_type_backport, and pydantic 2.14.0 (Oct 8) removed it. The server dies at import, so 010, 020 and 040 (the only tutorials that launch it and need its tool) time out on every branch. 0a79a58 pins pydantic<2.14 for that server in all four tutorials that launch it. Locally the server fails the MCP handshake on 2.14.0 and 2.14.1 and lists openai_web_search with the pin.