ADK Java Adds Explicit Workflow Input Requests: Why Resume Identity Matters More Than a Chat Prompt

Google ADK Java's October 23 commit 85780688fb0c1cb02f8c89a4fcbd6ec7dc0eba03 adds an experimental RequestInput workflow type. It gives a workflow node a way to ask for user data and wait for an answer. This October 26 review reads the implementation and upstream test changes at that commit. It does not claim the feature is available in every published package or that an end-to-end Java application was run locally.

The new boundary is a correlated event

The request becomes a long-running adk_request_input function call with an interrupt ID. Its fields can include a message, rendering payload and response schema. The answer uses the corresponding function-response ID. The implementation marks the request with the model role so history rewriting retains the call that the later answer references. Upstream tests cover pausing before a successor runs and continuing after a matching answer.

That is a different contract from writing a question into conversational prose. A UI needs to know which outstanding operation a form submission answers. A worker restarted after a pause needs the same correlation. The important object is the pending request, not the most recent sentence containing a question mark.

Design the pause as part of the state machine

Imagine an original procurement workflow. A classifier identifies a replacement part, a buyer supplies a delivery window, and a deterministic service checks stock before creating an order. The workflow should not hold a database transaction open while the buyer is away. Store the pending request, close the current unit of work, and wait for an authenticated answer.

The application's state can progress from awaiting_delivery_window to validating_answer, then checking_stock. Each transition should have an owner and a recorded reason. A browser refresh must redisplay the same outstanding request rather than generate a second order opportunity. The ADK change supplies workflow machinery; transaction scope, identity integration and ordering policy still belong to the surrounding application.

Answer shape is part of the contract

The pinned change adds schema checks when reconstructing answers. Its tests distinguish wrong types, missing required properties and undeclared object keys. A JSON-looking string remains a string when the schema permits a string. Error handling also avoids echoing an undeclared user-supplied key in the corresponding validation message.

For the procurement example, accept an explicit delivery-window object rather than asking the model to reinterpret free text at every resume. If the UI changes a field, version the pending form contract. An answer to yesterday's form must not silently acquire the meaning of today's schema. This versioning policy is an application recommendation, not a capability established by this commit.

A valid answer is not authorization

A correctly shaped delivery window says nothing about whether its sender may approve a purchase. Keep authorization outside model interpretation: bind the answer to the authenticated actor, tenant, workflow instance and exact pending operation. Recheck those bindings at the time the application accepts the answer. Reject stale or already-consumed submissions with a clear result.

Similarly, response-schema validation should not be described as a complete policy engine or full JSON Schema implementation. Read the specific validator and test the fields you rely on. Business constraints such as office opening hours, approval limits and allowed delivery addresses require additional deterministic validation. Never infer purchasing authority simply because a request resumed successfully.

Resume still needs replay and effect tests

Build a small acceptance matrix around the actual user journey: submit the expected answer, an answer with the wrong request ID, the same answer twice, an invalid field and an answer after the request expires. Restart the worker between asking and answering. Change stock availability during the pause and confirm that the application rechecks it instead of trusting the earlier observation.

The pinned upstream tests are valuable evidence of intended behavior, but they are not evidence that your storage backend, login integration or external order service survives these cases. In particular, do not generalize a local workflow test into a claim of exactly-once purchasing. Record external effects with idempotency and reconcile ambiguous outcomes using the order service's own identifiers.

Adopt from a pinned version

The source marks this API experimental. Check the artifact version or source revision you deploy, then build a minimal pause-and-resume integration before migrating a larger graph. Keep the prior path available until request persistence, schema evolution and duplicate submissions are covered. The useful architectural change is explicit waiting with correlation; the rest of the reliability case must be supplied by the application that embeds it.

Sources and evidence

Treat a human answer as an input to a specific recorded workflow request. Validate its shape, authenticate its sender and recheck business preconditions before resuming any external effect.