Add an example demonstrating imperative in-executor human-in-the-loop via Context.PostRequest

[PratikDhanave]

What

Adds examples/03-workflows/human-in-the-loop/imperative_request, a runnable sample where a custom *workflow.Executor raises a human-in-the-loop request imperatively from inside a handler via Context.PostRequest and consumes the matching *workflow.ExternalResponse itself. It is registered in cmd/verifyexamples/examples.go.

Why

Context.PostRequest is documented in workflow/workflow.go as a first-class user primitive and is exercised by TestPostRequestFromExecutor, but no committed example showed it — the only HITL sample (human_in_the_loop_basic) uses the higher-level workflow.RequestPort binding. This sample fills that gap and is framed explicitly as the low-level counterpart to the request-port binding, mirroring the .NET/Python guidance where the request-port abstraction and the imperative post-request path are presented as two ways to reach the same external-request/response protocol. Surfacing both keeps the Go examples aligned with the other SDKs.

How it works

The executor registers two raw handlers via RouteBuilder: on the initial string input it builds workflow.NewExternalRequest and calls wctx.PostRequest; on *workflow.ExternalResponse it reads resp.Data.As(port.Response) and yields the greeting. The driver runs with inproc.Default.Run, drains events to catch workflow.RequestInfoEvent, answers with a fixed value via run.Resume, and drains the resulting OutputEvent. The shape follows TestPostRequestFromExecutor.

Testing

• go build ./...
• go vet on the new example and cmd/verifyexamples
• Ran the example: it prints the raised prompt and completes with Hello, Ada!
• Deterministic (fixed answer), registered in verifyexamples with a MustContain assertion

[Copilot]

Pull request overview

Adds a new runnable Go workflow example demonstrating the imperative human-in-the-loop (HITL) pattern where an executor raises an external request via Context.PostRequest and handles the matching *workflow.ExternalResponse directly (as a lower-level counterpart to the existing request-port binding example). The example is registered with cmd/verifyexamples to ensure it stays runnable and output-stable.

Changes:

• Added examples/03-workflows/human-in-the-loop/imperative_request, showcasing in-executor imperative HITL using Context.PostRequest.
• Implemented a deterministic driver flow that waits for workflow.RequestInfoEvent, resumes the run with a fixed response, and prints the resulting output.
• Registered the example in cmd/verifyexamples/examples.go with MustContain output assertions.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.

File	Description
examples/03-workflows/human-in-the-loop/imperative_request/main.go	New runnable example demonstrating imperative Context.PostRequest + *workflow.ExternalResponse handling inside a custom *workflow.Executor.
cmd/verifyexamples/examples.go	Registers the new example with deterministic output checks for CI verification.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Parity Review: ✅ Aligned

This PR adds examples/03-workflows/human-in-the-loop/imperative_request/ — a runnable sample demonstrating Context.PostRequest used imperatively from inside an executor. No new exported Go APIs are introduced; all types used (Context.PostRequest, ExternalRequest, ExternalResponse, RequestPort, NewExternalRequest, ProtocolBuilder, ExecutorBinding, YieldOutput) are pre-existing public surfaces.

Cross-repo parity check:

SDK	Equivalent coverage
Python	python/samples/03-workflows/human-in-the-loop/sequential_request_info.py and other HITL samples demonstrate the imperative external-request/response protocol
.NET	dotnet/samples/03-workflows/HumanInTheLoop/HumanInTheLoopBasic covers the equivalent request-port/external-request flow

The example closes a documented gap in docs/dotnet-go-sdk-feature-comparison.md ("Workflow external requests/HITL" row) and is framed explicitly as the low-level counterpart to human_in_the_loop_basic, matching the two-path guidance present in both Python and .NET samples.

No parity issues found. The parity-approved label already present is correct. No public-api-change label needed — no exported Go API surface changed.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by Go API Consistency Review Agent · 33.1 AIC · ⌖ 5.59 AIC · ⊞ 5.9K · ◷

[gdams]

Looks like you checked this binary in by accident