Skip to content

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

Open
PratikDhanave wants to merge 2 commits into
microsoft:mainfrom
PratikDhanaveFork:hitl-imperative-request-example
Open

Add an example demonstrating imperative in-executor human-in-the-loop via Context.PostRequest#750
PratikDhanave wants to merge 2 commits into
microsoft:mainfrom
PratikDhanaveFork:hitl-imperative-request-example

Conversation

@PratikDhanave

Copy link
Copy Markdown
Contributor

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 AI review requested due to automatic review settings July 24, 2026 04:14
@PratikDhanave
PratikDhanave requested a review from a team as a code owner July 24, 2026 04:14

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 github-actions Bot added the parity-approved Go API consistency review found no parity issues label Jul 24, 2026
@github-actions

This comment has been minimized.

Adds examples/03-workflows/human-in-the-loop/imperative_request showing a
custom executor that raises an ExternalRequest imperatively with
Context.PostRequest and consumes the matching ExternalResponse itself,
the low-level counterpart to the request-port binding in
human_in_the_loop_basic. Registers it in verifyexamples.
@PratikDhanave
PratikDhanave force-pushed the hitl-imperative-request-example branch from c0802dd to d863db3 Compare July 24, 2026 09:30
@github-actions

This comment has been minimized.

Comment thread imperative_request

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like you checked this binary in by accident

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Parity Review — ✅ No Issues

This PR adds examples/03-workflows/human-in-the-loop/imperative_request demonstrating Context.PostRequest for imperative human-in-the-loop, and registers it in cmd/verifyexamples. No exported Go APIs are added or changed.

Cross-repo sample parity: The upstream Python samples tree (python/samples/03-workflows/human-in-the-loop/) already covers imperative request-info patterns across several samples (sequential_request_info.py, concurrent_request_info.py, etc.). The .NET tree has HumanInTheLoop/HumanInTheLoopBasic. This new Go example correctly fills the same slot — showing the low-level PostRequest path as a complement to the existing RequestPort-based sample — consistent with how both upstream SDKs present the two HITL paths side by side.

The parity-approved label remains correct. No public-api-change label is needed as no exported identifiers were touched.

Generated by Go API Consistency Review Agent · sonnet46 · 25 AIC · ⌖ 5.62 AIC · ⊞ 5.7K ·

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

parity-approved Go API consistency review found no parity issues

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants