<@U0BME18CF7S> can you please finalize this PR? <h...
# automations-debug
c
@fresh-machine-37269 can you please finalize this PR? https://github.com/OpenHands/software-agent-sdk/pull/3673 See CI is failing, and then make it ready for review.
šŸ‘€ 1
f
šŸ¤– On it! View progress here: oss-agent-canvas.ngrok.dev/conversations/…
ā³ Still working — this is taking longer than this run allows. Follow along at the link above; mention me again for an update.
c
@fresh-machine-37269 continue please
šŸ‘€ 1
f
ā³ Still working — this is taking longer than this run allows. Follow along at the link above; mention me again for an update.
c
@fresh-machine-37269 what's holding you, you should have completed this task long ago. is it difficult?
šŸ‘€ 1
f
āœ… Done! Done — PR #3673 is now ready for review. Here's what I fixed and why CI was failing. What was wrong 1. Merge conflict:
main
had since added
56_structured_output.py
and
57_prompt_hooks
, which collided with the PR's
56_ask_oracle_tool
directory. This is why the PR was in
CONFLICTING
state. 2.
check-examples
failure
: the new example wasn't documented in the
OpenHands/docs
repo, and the existing docs PR #566 was stale (referenced a removed
oracle_llm_profile
setting and the old
55_
path). 3. One unresolved review thread flagging that the PR description contradicted the implementation (the old
oracle_llm_profile
claim vs. the actual convention-based
oracle
profile design). What I did • Rebased/merged
main
into
feat/ask-oracle-tool
and resolved the conflict, then renumbered the example to
58_ask_oracle_tool
(updating
tests/examples/test_examples.py
, the
.pr/
evidence files, and the example's own docstring). The PR is now
mergeable: True
. • Updated the docs PR (#566) in
OpenHands/docs
to match: it now documents the convention-based
oracle
profile (no
oracle_llm_profile
setting) and references
58_ask_oracle_tool
. • Updated the SDK PR description to remove the stale `oracle_llm_profile`/`54_ask_oracle`/`gpt-5-nano` references while leaving the
HUMAN:
section untouched. • Resolved the last review thread with a reply explaining the description is now fixed. • Marked the PR ready for review (
draft: False
). Remaining CI note: the
Python API
,
REST API (OpenAPI)
,
Check OpenAPI Schema
, and
Update PR description
checks show red on the latest commit, but I confirmed locally these are environmental — the SDK API breakage check passes (
No breaking changes detected
),
uv sync --frozen
succeeds, and the OpenAPI export works; the job logs show GitHub API 503 "No server available" errors. They should turn green on re-run once GitHub's API stabilizes.
šŸ‘ 1
c
@modern-fireman-99755 FWIW this is a pretty amazing time, 1h 20 mins for a simple task. I feel like the GH issues might be part of why. But I'm impressed it stayed with it! Instead of erroring out or, actually, the agent could have given up. It went through 2 timeouts and still worked.šŸŽ‰
m
haha... it was because of the GH outrage of today šŸ™‚
c
@fresh-machine-37269 Great! We're in a good place now, but please read the latest reviews and inline review threads if any is unsolved, and address them.
šŸ‘€ 1
f
šŸ¤– On it! View progress here: oss-agent-canvas.ngrok.dev/conversations/…
āœ… Done! Done — I read the latest review and inline threads on PR #3673 and addressed the one outstanding material finding. The key issue was that the
ask_oracle
executor loaded its profile via
LLMProfileStore().load()
and called
make_llm_completion()
directly, bypassing the conversation's
llm_registry
. That meant Oracle token/cost usage never reached
ConversationStats
, and the code touched the private
conversation._cipher
. Fix (pushed as
a66c2a529
):
• Switched to
conversation.get_or_create_profile_llm(profile_name="oracle", usage_id="oracle:oracle")
, matching
vision_inspect
. • This registers the Oracle LLM in the registry so its metrics are tracked in conversation stats, binds conversation context (prompt-cache/session affinity), caches across calls, and removes the direct
_cipher
access. • Added a
conversation is None
guard returning an error observation, consistent with
switch_llm
. • Updated the two affected tests. Verification:
ask_oracle
tests (6), the example-discovery test,
ruff check
,
ruff format
, and full pre-commit (incl. pyright and import-dependency rules) all pass. I also replied to the two open inline threads explaining the change. The remaining review notes were either already resolved (the
.pr/
artifacts are auto-cleaned on approval, and the PR description was already updated to drop the stale
oracle_llm_profile
claim) or minor/non-blocking (the
response
field duplication and the broad
except
, both flagged as harmless/consistent with existing patterns).