Skip to content

feat(agent): add further_questions to ConversationResponse - #564

Merged
hogan-yuan merged 1 commit into
mainfrom
feat/agent-further-questions
Aug 11, 2026
Merged

feat(agent): add further_questions to ConversationResponse#564
hogan-yuan merged 1 commit into
mainfrom
feat/agent-further-questions

Conversation

@hogan-yuan

Copy link
Copy Markdown
Member

What

The agent workflow_finished event's outputs carry a further_questions list — the "you might also ask" follow-up suggestions — that the SDK silently dropped. WorkflowOutputs only modeled answer and references, so the field never reached callers on either the streamed WorkflowFinished outcome or the folded ConversationResponse.

Change

  • Core (rust): add further_questions: Option<Vec<String>> to WorkflowOutputs and ConversationResponse, and thread it through ConversationResponse::from_stream_parts.
  • All bindings: surface the field, mirroring exactly how the existing string-list fields are exposed:
    • Python#[pyclass] ConversationResponse + From impl + openapi.pyi stub
    • Node.js — napi ConversationResponse + From impl + index.d.ts
    • Java — JNI ConversationResponse (#[java(objarray)]) + ConversationResponse.java (String[] getter / toString)
    • CCConversationResponse (*const *const c_char + num_further_questions, mirroring reference_domains); longbridge.h regenerated by cbindgen

Tests

Extended the Rust workflow_finished deserialize test to cover further_questions threading. Each binding crate builds clean.

Why now

Downstream (longbridge-terminal) is moving its hand-rolled agent SSE client onto AgentContext; this is the one field the SDK was missing for that migration to be lossless.

The agent workflow_finished event's outputs carry a further_questions
list (suggested follow-ups, "you might also ask") that the SDK dropped:
WorkflowOutputs only modeled answer and references, so the field was
lost on both the streamed WorkflowFinished outcome and the folded
ConversationResponse.

Add further_questions: Option<Vec<String>> to the core WorkflowOutputs
and ConversationResponse, thread it through from_stream_parts, and expose
it across every binding (Python, Node.js, Java, C) mirroring how the
existing string-list fields are surfaced. The C header is regenerated by
cbindgen.
@hogan-yuan
hogan-yuan merged commit f51b3a3 into main Aug 11, 2026
99 of 112 checks passed
@hogan-yuan
hogan-yuan deleted the feat/agent-further-questions branch August 11, 2026 09:15
hogan-yuan added a commit to vingel/longbridge-terminal that referenced this pull request Aug 11, 2026
Replace the hand-rolled reqwest/SSE agent client with the SDK's
AgentContext (longbridge >= 4.4.2), pinned for now to the
feat/agent-further-questions branch that adds the one field the SDK was
missing (ConversationResponse.further_questions).

- openapi/context.rs: add a global AGENT_CTX / agent(), and drop the
  SSE-only host-resolution scaffolding this feature had added
  (resolve_endpoints, effective_http_url, captured_http_url_override,
  the using_api_key global accessor, and the main() .env capture).
- auth.rs: drop access_token(); the plaintext OAuth token no longer
  leaves the SDK now that the SSE transport goes through HttpClient.
- client.rs: LbAgentApi lists via agent().workspaces()/.agents();
  stream_conversation drives conversation_streamed /
  continue_conversation_streamed and maps ConversationStreamEvent onto
  the existing AgentEvent. Shared rate limiter + pre-stream 429 retry
  are preserved.
- events.rs: the raw SSE parser (parse_data_line / SseLineBuffer) is now
  test-only; the SDK owns wire parsing, and the golden fixture still
  cross-checks the event shapes the mapping depends on.
- chat.rs: call sites use a typed ConversationRequest instead of
  (path, body).

Depends on longbridge/openapi#564; once merged, drop the branch pin in
Cargo.toml and cargo update back to main.
hogan-yuan added a commit to longbridge/openapi-go that referenced this pull request Aug 11, 2026
## What

The agent `workflow_finished` event's `outputs` carry a
`further_questions` list — the "you might also ask" follow-up
suggestions — that the Go SDK dropped. `ConversationResponse` and the
internal `workflowOutputs` only modeled `answer`/`references`, so the
field was lost on both the blocking response and the streamed
`WorkflowFinishedEvent`.

## Change

- Add `FurtherQuestions []string` (`json:"further_questions"`) to
`ConversationResponse` and its `UnmarshalJSON` raw struct.
- Add it to the internal `workflowOutputs` and thread it through the
`workflow_finished` fold in `stream.go`.

## Tests

Extended the blocking `TestUnmarshalSucceededConversationResponse` and
the streamed `workflow_finished` assertion to cover `FurtherQuestions`.
`go test ./agent/`, `go vet`, and `gofmt` all clean.

Companion to longbridge/openapi#564 (same field across the other
language SDKs).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant