Skip to content

fix: forward timeout_s as-is to let SDK derive effort-based deadline - #17

Merged
tyler5673 merged 1 commit into
mainfrom
dx-789-fix-timeout_s-fallback
Aug 21, 2026
Merged

fix: forward timeout_s as-is to let SDK derive effort-based deadline#17
tyler5673 merged 1 commit into
mainfrom
dx-789-fix-timeout_s-fallback

Conversation

@tyler5673

Copy link
Copy Markdown
Contributor

Summary

youdotcom_research_background substituted 120.0 when ResearchInput.timeout_s was None, preventing the SDK from deriving its effort-based default (600s for standard, 14400s for frontier via _resolve_default_timeout()). This capped every effort tier at 120s, causing frontier tasks to time out prematurely.

The fix forwards timeout_s as-is (including None) so the SDK decides the deadline.

Closes DX-789

Changes

  • activities.py: timeout_s=inp.timeout_s (was inp.timeout_s if inp.timeout_s is not None else 120.0)
  • models.py: Updated timeout_s docstring to describe SDK-derived defaults
  • tests/test_activities.py: Updated assertion to expect None forwarded
  • CHANGELOG.md: Added entry

Verification

  • ruff: passed
  • mypy: clean (7 source files)
  • pytest: 79 passed, 0 warnings

The research_background Activity substituted 120.0 when timeout_s was None,
preventing the SDK from deriving its effort-based default (600s standard,
14400s frontier). Now forwards timeout_s unchanged so the SDK decides.

Closes DX-789

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
@tyler5673
tyler5673 marked this pull request as ready for review August 21, 2026 21:54
@tyler5673
tyler5673 merged commit 35f01c0 into main Aug 21, 2026
5 of 7 checks passed
@tyler5673
tyler5673 deleted the dx-789-fix-timeout_s-fallback branch August 21, 2026 21:54
tyler5673 added a commit that referenced this pull request Aug 21, 2026
The Activity now forwards timeout_s as-is (PR #17 merged), so the SDK
derives the effort-based deadline itself. Updated the comment that
described the old 120s substitution behavior.

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
tyler5673 added a commit that referenced this pull request Sep 3, 2026
* feat: add Nexus Service support (workflow-backed Operations)

Rebased onto main with PR #15 (SDK 3.1.2 + attribution header) and
PR #16 (extraction parameter) merged. Squashes the nexus spike into
one clean commit.

- YouDotComService exposes all six Activities as async Nexus Operations
- contract.py holds the Nexus contract with SDK response models
- workflows.py ships six thin backing Workflows with per-Activity ceilings
- Idempotency key support for deduplication of Nexus StartOperation retries
- Unit tests covering contract, handler, and sandbox registration
- Integration tests for live Nexus round-trip (gated behind -m integration)

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>

* fix: update stale DX-776 comments, fix annotated_types passthrough, correct timeout_s comment

- contract.py, nexus.py: SDK 3.1.2 shipped lazy imports (PEP 562), so the
  imports_passed_through() wrapper is belt-and-braces rather than load-bearing.
  Updated comments that referenced DX-776 as future work.
- workflows.py: comment claimed the Activity forwards timeout_s untouched
  but activities.py substitutes 120s when timeout_s is None, preventing the
  SDK effort-based deadline derivation. Corrected to describe actual behavior.
- plugin.py: re-added annotated_types to _PASSTHROUGH_MODULES, eliminating
  13 UserWarning messages about late import under the workflow sandbox.

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>

* fix: update workflows.py comment after PR #17 rebase

The Activity now forwards timeout_s as-is (PR #17 merged), so the SDK
derives the effort-based deadline itself. Updated the comment that
described the old 120s substitution behavior.

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>

* fix: contents Operation result model and research background guard

ContentsOutput wrapped the wrong SDK model: Contents (the search
extraction shape) instead of ContentsResponse (the contents endpoint
response), silently dropping url, title, and metadata from every
result element.

The research Operation accepted ResearchInput.background=True, but
with background=True the SDK returns a task handle that can never
validate as the Operation's ResearchResponse result. It now rejects
background=True with a non-retryable YouValidationError before any
billable call; research_background is the Operation for that mode.

Also restructures the CHANGELOG Unreleased section so it merges
cleanly against main's 1.1.0 release.

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>

---------

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
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