fix(connectors): Jira checks time out their requests instead of hanging

Merged
EV
20h ago
+382-65

Description

Backend PR for the connector checks redesign, stacked on #16206. The Jira checks now time out their requests. Before, the Jira client had no request timeout, so a slow Jira held a check until the runner's hang guard (5 minutes on a form run, 10 minutes on other runs).

Gateway (jira/source_operations.py)

  • The operations that the checks call take fast: bool = False, as in the Confluence, Slack and Notion gateways.
  • fast=True uses a second cached client: a 10 second connect and read timeout, and no SDK retries. The SDK retries a connection error, 429 and 503 with sleeps of up to a minute, so the timeout alone does not bound a check.
  • On a fast=True call, a request timeout raises JiraTimeoutError, a JiraApiError with the request method and URL. Error Details show the request.

What indexing sees: nothing changes. Indexing, permission sync and group sync call the operations without fast. They use the default client with the same arguments as before: no timeout and 3 retries (the SDK's defaults). A requests.Timeout on that path is not translated.

Checks (jira/capability_checks.py)

  • Every gateway call in the checks passes fast=True.
  • Sign-in: a request timeout gives "Sign-in timed out" / "Jira did not answer the sign-in in time. Re-run, or check that Jira is reachable from Onyx.", as in the design. It is an UnreachableValidationError, so it is Failed on a form run (fails_when_unreachable=True) and Incomplete on other runs. A timeout of the scoped token's tenant_info call gives the same row. A refused connection still gives "Cannot reach Jira".
  • Other checks: a request timeout gives the design's shared row, "Timed out" / "The check stopped because Jira did not answer in time. Re-run the checks.". It is Incomplete on all runs.

One change from the design: the row's error_kind is unreachable, not timeout. The framework gives timeout only to the runner's own hang-guard TimeoutError, and this PR does not change the framework. The state, the row text and the Stack Trace are the same for both kinds.

How Has This Been Tested?

  • New unit tests (test_jira_check_request_timeout.py): the fast client's timeout and retries, the indexing client's unchanged arguments, the separate client caches, the typed timeout with its request, the untranslated timeout on the indexing path, the sign-in timeout on form and non-form runs, the tenant_info timeout, a refused connection, and a timeout after sign-in.
  • Existing Jira check tests updated for the fast=True argument.
  • Connector and server unit tests: 4311 passed, 24 skipped, 1 failed. The failure (web/test_browser_lifecycle.py::test_download_is_not_retried_and_does_not_relaunch_browser) is in the web connector, which this PR does not change. Jira unit tests: 144 passed. ty and pre-commit are clean.
  • I did not run the live daily test: there are no Jira tokens in this session.

Additional Options

  • [Optional] Please cherry-pick this PR to the latest release version.
  • [Optional] Override Linear Check

Generated by Claude Code

Summary by cubic

Jira capability checks now time out requests after 10 seconds instead of hanging until the runner's hang guard (5 minutes on a form run, 10 minutes on other runs). Checks call the gateway with fast=True, which uses a separate cached client with a 10-second timeout and no SDK retries; a timeout raises JiraTimeoutError and maps to a "Timed out" row, or "Sign-in timed out" for the sign-in check, while a refused connection still shows "Cannot reach Jira". Indexing, permission sync, and group sync keep the default client with no timeout and 3 retries, so their behavior is unchanged. The timed-out row has error_kind unreachable rather than timeout, which is reserved for the runner's own hang guard.

Summary by CodeRabbit

  • Bug Fixes
    • Improved Jira connection and capability checks with faster validation requests.
    • Added clearer handling and reporting when Jira requests time out or cannot be reached.
    • Preserved standard timeout and retry behavior for regular Jira indexing operations.
  • Tests
    • Expanded coverage for Jira timeout scenarios, connection failures, authentication, and capability checks.