OpenAI streaming fails: 'ResponseCreatedEvent' object has no attribute 'choices'

[sevelar05]

Summary

Wiki generation fails on the OpenAI provider. respond_stream in
api/chat/_stream.py consumes the stream assuming Chat Completions
chunks (chunk.choices), but adalflow returns Responses API events,
which have no choices attribute.

Environment

• adalflow 1.1.3
• openai 1.109.1
• Python 3.11
• Docker build from main
• Provider: openai, model gpt-4o

Error

2026-09-07 08:52:01 - ERROR - deepwiki.api.services.research - Error with openai API: 'ResponseCreatedEvent' object has no attribute 'choices' Traceback (most recent call last): File "/app/api/services/research.py", line 267, in stream_and_fallback async for chunk in streamer.respond_stream(prompt_func()): File "/app/api/chat/_stream.py", line 169, in respond_stream chunk.choices File "/opt/venv/lib/python3.11/site-packages/pydantic/main.py", line 1042, in getattr raise AttributeError(...) AttributeError: 'ResponseCreatedEvent' object has no attribute 'choices'

The stream raises before yielding any text, so the downstream
structure parser receives an empty string and fails with a second,
misleading error:

File "/app/api/services/wiki/structure.py", line 200, in parse_wiki_structure raise ValueError("No valid <wiki_structure> XML found in response")

This second error is a symptom, not a separate bug. Worth noting
because there are existing issues reporting the XML error with
unrelated or unknown causes.

Steps to reproduce

1. Build the image from main (docker compose build --no-cache)
2. Set OPENAI_API_KEY in .env
3. Start the service (docker compose up -d)
4. Generate a wiki for any repository with the OpenAI provider selected
5. Observe the traceback in docker compose logs deepwiki

Root cause

self.client.acall(api_kwargs=..., model_type=ModelType.LLM) in the
OpenAI streamer class returns Responses API events. The annotation on
that line (AsyncStream[ChatCompletionChunk]) is a string literal and
is not enforced at runtime, so the mismatch surfaces only on the first
iteration.

Proposed fix

Make the loop tolerant of both shapes, using getattr so neither
attribute access can raise. Happy to open a PR.