Repository navigation
Framework examples (adk/langgraph/openai) crash with SpawnSafetyError — tool functions defined inside main() instead of module level #443
Description
Summary
Several framework example files fail immediately with SpawnSafetyError because they define their tool callables inside main() (local/nested functions). The SDK's spawn-safety probe requires tools to be importable by qualified name, and its own error message states the fix. This is an examples defect — the tools should be defined at module level.
Environment
conductor-oss/python-sdk@main(also repros on the releasedconductor-agent-sdk)- conductor-oss server
3.32.0-rc.10, modelanthropic/claude-sonnet-4-6, macOS
Repro
cd examples/agents
export CONDUCTOR_SERVER_URL=http://localhost:8080/api \
AGENTSPAN_SERVER_URL=http://localhost:8080/api \
AGENTSPAN_LLM_MODEL=anthropic/claude-sonnet-4-6 \
PYTHONPATH=$PWD
python3 adk/14_callbacks.pyActual
AttributeError: Can't get local object 'main.<locals>.lookup_customer'
...
conductor.ai.agents.runtime._worker_entries.SpawnSafetyError: worker 'lookup_customer'
is not spawn-safe (AttributeError("Can't get local object 'main.<locals>.lookup_customer'")).
Define the callable at module level (importable by qualified name).
Cause
The tool functions are declared inside main(), so they can't be pickled/imported by worker processes → the SDK's probe_spawn_safety (intentionally) rejects them. The SDK behavior is correct and even prints the remedy: "Define the callable at module level." Passing examples already define tools at module scope.
Affected files (17)
adk/14_callbacks.py
adk/15_global_instruction.py
adk/16_customer_service.py
adk/17_financial_advisor.py
adk/18_order_processing.py
adk/19_supply_chain.py
adk/20_blog_writer.py
langgraph/03_memory.py
langgraph/13_multi_turn.py
langgraph/27_persistent_memory.py
openai/02_function_tools.py
openai/04_handoffs.py
openai/05_guardrails.py
openai/07_streaming.py
openai/08_agent_as_tool.py
openai/09_dynamic_instructions.py
openai/10_multi_model.py
Suggested fix
Move each example's @tool/tool functions from inside main() to module level so they're importable by qualified name (matching the pattern used by the examples that run successfully).
Activity
nickorkes commentedon Jul 26, 2026
Worth reading before fixing this one: #448 hits the same transport code through a different trigger.
There the tool is already defined at module level and it still fails, with
PicklingError: ... it's not the same object as __main__.get_inventoryrather thanAttributeError: Can't get local object.That matters for the fix here. Moving the example tools out of
main()will make these examples pass, but any OpenAI@function_toolat module level still fails.@function_toolrebinds the module global to aFunctionTool, and_CONTAINER_ATTRSonly unwraps.funcand.coroutine, so the container hop that covers LangChain does not cover OpenAI.#448 also has a Linux reproduction, which shows this is not platform-specific, and a suggested by-value transport with cloudpickle that would cover both cases.
deeptireddy-lab commentedon Jul 26, 2026
correct for openai it has nothing to so with the module level. for langgraph and adk, it does.
kowser-orkes commentedon Jul 28, 2026
Example fix are on this PR: #449