increase worker threads for ci

[zanesq]

Summary

fix failing tests for goose-acp

thread 'test_permission_persistence::allow_always' (4774) has overflowed its stack
fatal runtime error: stack overflow, aborting
error: test failed, to rerun pass `-p goose-acp --test server_test`

Caused by:
  process didn't exit successfully: `/home/runner/work/goose/goose/target/debug/deps/server_test-d0cb26eab9d9a4eb --skip 'scenario_tests::scenarios::tests'` (signal: 6, SIGABRT: process abort signal)
Error: Process completed with exit code 101.

[jamadeo]

huh - how does more threads help with the stack size? I thought maybe something to do with too many tasks and too little threads but claude tells me that doesn't make sense because each task has its own stack

[zanesq]

@jamadeo I actually used goose to create this and the test is passing now so I figure it's working. I asked goose about your question and it said:

In tokio, async tasks don't have their own stacks in the traditional sense. Instead, async functions compile down to state machines that live on the heap. The stack is only used during the synchronous portions when a task is actively being polled.

So the stack overflow is happening during the synchronous execution of polling a deeply nested future. The call stack builds up from:

1. The test harness calling the async test
2. run_acp_session
3. ClientToAgent::builder()...connect_to()...run_until()
4. Deep into the sacp library's message handling
5. Through the ACP server's handler chain
6. Into goose's agent code

With a single-threaded runtime, all of this happens on one thread's stack. The entire nested async call chain gets polled on that single stack.

With a multi-threaded runtime, when you tokio::spawn a task, it can run on a different worker thread. Looking at the code, spawn_server_in_process does tokio::spawn for the server. In multi-threaded mode, the server runs on one thread's stack while the client/test runs on another. This splits the deep call chain across two stacks instead of one.

So it's not about "more stack" - it's about distributing the call depth across multiple threads' stacks via spawn points.

[michaelneale]

yeah - threads in rust and other languages often are green threads, not always native (they map to it - swift and haskell etc also do this) - so a stack isnt' really an os stack for a thread if that makes sense? (in JVMs they are, and C++ etc but other langauges like to manage things themselves)

task/thread -> maps to OS thread (pool) not 1:1 usually.