"FleetApi.start()" uses default 30s timeout but "fleet.start" RPC blocks until fleet completes

[Rasaboun]

Summary

session.rpc.fleet.start() is unusable for any non-trivial workload because it inherits the 30s default timeout from JsonRpcClient.request(), but the session.fleet.start RPC is a long-running blocking call that only responds once the fleet finishes and the session goes idle.

The problem

FleetApi.start() is a thin wrapper with no timeout parameter:

# copilot/generated/rpc.py
class FleetApi:
    async def start(self, params: SessionFleetStartParams) -> SessionFleetStartResult:
        params_dict = {k: v for k, v in params.to_dict().items() if v is not None}
        params_dict["sessionId"] = self._session_id
        return SessionFleetStartResult.from_dict(
            await self._client.request("session.fleet.start", params_dict)
        )

It calls self._client.request(...) which defaults to 30s:

# copilot/jsonrpc.py
async def request(self, method, params=None, timeout=30.0):
    ...
    return await asyncio.wait_for(future, timeout=timeout)

Any fleet workload taking more than 30s raises asyncio.TimeoutError.

Observed behavior

I ran 5 tests against github-copilot-sdk==0.1.26rc0 / @github/copilot@0.0.411 to characterize fleet.start:

Test	Result
Trivial plan (1 task)	fleet.start returned after 47.6s — same time as SESSION_IDLE
No plan at all	Returned after 8.3s with started=True (agent had nothing to do)
Typed API, trivial plan	Returned after 14.7s — happened to fit within 30s
notify instead of request	Fleet did not run at all — must be a request
Precise ordering (2 tasks)	FLEET_RETURNED and SESSION_IDLE at exactly the same time (23.04s)

Key findings

1. fleet.start blocks until the fleet finishes — it returns at the same time as SESSION_IDLE, not when the fleet is "started"
2. notify does not work — fleet.start must be called as a JSON-RPC request
3. started=True is always returned (even with no plan), so the field doesn't convey meaningful status
4. The 30s default timeout causes TimeoutError for any real workload — forcing users to bypass the typed API

Current workaround

Bypass FleetApi.start() and call the raw RPC with a longer timeout:

params = SessionFleetStartParams(prompt="implement the plan")
params_dict = {k: v for k, v in params.to_dict().items() if v is not None}
params_dict["sessionId"] = session.session_id

raw_result = await session._client.request(
    "session.fleet.start", params_dict, timeout=600.0
)
result = SessionFleetStartResult.from_dict(raw_result)

Reproduction

import asyncio
from copilot import CopilotClient
from copilot.generated.rpc import Mode, SessionFleetStartParams, SessionModeSetParams

async def main():
    client = CopilotClient()
    await client.start()
    session = await client.create_session(
        {"model": "gpt-5-mini", "streaming": "true", "reasoning_effort": "low"}
    )

    await session.rpc.mode.set(SessionModeSetParams(mode=Mode.PLAN))
    await session.send_and_wait(
        {"prompt": "Create a plan with 4 independent tasks: write factorial.py, palindrome.py, fibonacci.py, bubblesort.py"},
        timeout=120.0,
    )

    await session.rpc.mode.set(SessionModeSetParams(mode=Mode.AUTOPILOT))

    # This will raise asyncio.TimeoutError for any plan that takes >30s
    result = await session.rpc.fleet.start(
        SessionFleetStartParams(prompt="implement the plan")
    )

asyncio.run(main())

Suggested fix

Make fleet.start return immediately with an acknowledgment (started=True) and let the caller wait via SESSION_IDLE events. This would match what the return type name (started) implies.

Environment

• github-copilot-sdk: 0.1.26rc0
• @github/copilot CLI: 0.0.411
• Python: 3.12
• macOS Darwin 25.2.0

[github-actions]

Thank you for this detailed bug report, @Rasaboun!

I've labeled this as a bug affecting the Python SDK. Your analysis clearly shows that FleetApi.start() inherits an inappropriate 30s timeout for a long-running blocking RPC call, making it unusable for non-trivial workloads.

The reproduction steps, empirical data, and suggested fix are excellent. This will help the team address the issue effectively.

AI generated by Issue Triage Agent

[SteveSandersonMS]

@Rasaboun Thanks for reporting this. I've looked into it, and I think this report is partially correct but not entirely.

The RPC fleet.start call does not wait until the fleet has finished. On the server side, it returns as soon as the fleet has started.

However, you are correct that the Python SDK was incorrectly hardcoding the timeout to 30s. All the other SDKs allow unlimited time and leave it up to the caller to set a time limit if they want. The approach varies across languages (e.g., in .NET it's a CancellationToken), and in Python it can be done by wrapping the call. If there's demand for adding a timeout parameter to the call we can do that later but today that wouldn't be functionally different than wrapping the call in a timeout.

I'm filing #592 to address the underlying issue.