How to use LongRunningTool in Long Execution situation other than "HITL"

[maxx1958]

It's not "HITL."
the tool has a long execution time, so when the user has to wait,

I wonder how to turn the user so that user can ask the next question without blocking(waiting).
and
when the tool is completed, it should be able to inform the user.

The example mentions only a case for HITL.
HITL injects new_message from outside back to Agent.
but. I want to know it without user input(like approval)

https://github.com/google/adk-python/tree/main/contributing/samples/tools/long_running_functions

I am curious about the process from start to in-progress to complete ( not HITL ).

how agent know tool is completed. and how to get result of tool?

[barry166]

From the docs/samples, LongRunningFunctionTool is a resume handshake, not a background runner by itself. The same pattern used for HITL applies when there is no human approval: start the job in your tool, return something like { "status": "in-progress", "job_id": "..." }, store the original function call id/name (and invocation_id if you are using resumability), then have your worker/app resume the agent when the job finishes.

new_message = types.Content(
    role="user",
    parts=[types.Part(function_response=types.FunctionResponse(
        id=original_function_call.id,
        name=original_function_call.name,
        response={"status": "completed", "result": result},
    ))],
)

async for event in runner.run_async(
    user_id=user_id,
    session_id=session_id,
    invocation_id=paused_invocation_id,
    new_message=new_message,
):
    ...

The role="user" part is just how ADK receives the external function response back into the invocation; it does not mean a human had to approve anything. ADK only knows the tool is complete when your application sends that FunctionResponse, so if the user should keep chatting meanwhile, model the work as an app-level background job and send progress/completion back into the same session or your notification channel when the worker finishes.

[maxx1958]

@barry166
Thank you for your answer. However, how does the user know when the task is completed?

The flow should be as follows:

Tool call -----> return pre-response ---> long running ---> (tool completed) ---> how to know user ?? ---> user(or FE) or any outside of runner --> send Function Response to run_async as new message.

When runner.run_async is called on the worker, the connection between fe and the agent is broken, so the user cannot receive events.

Alternatively,

when injecting a function response via append_event,

there were occasional instances where a message indicating that the previous tool had terminated was displayed to the agent, even though the user had connected to the agent with a new request. (This was not always the case; the termination of many past tools was ignored.)

In that case, should LongRunningTools, excluding HITL, remain in a waiting state for an extended period? (Can't they perform BG jobs?)

Should they be prevented from receiving additional user input while waiting for the tool's final result?

[akkupratap323]

The missing piece is an application-level job channel. LongRunningFunctionTool supplies the pause/resume protocol, but it is not a background worker or a notification transport.

For the flow you described, I would structure it like this:

1. The tool validates the request, enqueues a durable job, and returns/persists {job_id, status: "in-progress"} together with the original function-call ID and session identity.
2. A worker runs independently of the ADK invocation and writes progress/result to a durable job store.
3. The frontend subscribes to job events through a separate WebSocket/SSE/pub-sub channel (with GET /jobs/{job_id} as reconnect/poll fallback). Closing the original run_async stream must not close this channel.
4. On completion, a backend coordinator sends exactly one matching FunctionResponse and starts/resumes runner.run_async. It forwards the resulting agent events to that same notification channel.

The user therefore learns that the job finished from your application channel; ADK learns it finished only from the matching FunctionResponse. The role="user" envelope is the protocol input used to resume the invocation—it does not imply that a human typed another message.

If the user must keep chatting while the job runs, avoid concurrently appending a completion and an unrelated user turn to the same session history. Serialize runner writes per session (an async lock/queue is enough for one process), or put the background task in a child/separate session and post a notification/result back to the conversational session when it is idle. Otherwise an old completion can be consumed during a newer turn, which matches the intermittent behavior you saw.

Also make completion idempotent: persist a pending -> completed -> delivered transition keyed by job_id, and reuse the original function-call ID. A worker retry should not inject the result twice.

If the final result does not need another model turn, you can notify the frontend directly and store the result without resuming the agent. Resume with FunctionResponse only when the agent/workflow must interpret the result or continue subsequent steps.

This is consistent with ADK's guidance for long monitoring jobs: keep the persistent worker outside the agent session and initiate/resume an ADK run when there is something to deliver: #2426