fix(source-google-ads): mount TimeoutHTTPAdapter on parent-stream sessions (4.2.6-rc.2)#77663
Conversation
…sions Co-Authored-By: gl_anatolii.yatsuk <gl_anatolii.yatsuk@airbyte.io>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
👋 Greetings, Airbyte Team Member!Here are some helpful tips and reminders for your convenience. 💡 Show Tips and TricksPR Slash CommandsAirbyte Maintainers (that's you!) can execute the following slash commands on your PR:
📚 Show Repo GuidanceHelpful Resources
|
|
Deploy preview for airbyte-docs ready!
Deployed with vercel-action |
|
Co-Authored-By: gl_anatolii.yatsuk <gl_anatolii.yatsuk@airbyte.io>
…y stream's session
|
/ai-review
Reviewing PR for connector safety and quality.
|
AI PR Review ReportReview Action: NO ACTION (INCONCLUSIVE)
📋 PR DetailsConnector & PR InfoConnector(s): Risk LevelLevel: 4 — High Risk Level is reported for downstream consumers (e.g. auto-merge policy, reviewer routing). It does not change the review action — APPROVE here means "no blocking objection," not "safe to merge unattended." Review Action DetailsNO ACTION (INCONCLUSIVE) - The Live / E2E Tests gate is UNKNOWN because the
🔍 Gate Evaluation DetailsGate-by-Gate Analysis
Behavioral Changes — Detail:
Test Coverage — Evidence:
PR Hygiene — Evidence:
📚 Evidence ConsultedEvidence
❓ How to RespondProviding Context or JustificationThe Live / E2E Tests gate is UNKNOWN because pre-release checks are still pending. You have two options:
Option 1: PR Description (recommended) ## AI PR Review Justification
### Live / E2E Tests
[Your explanation with verifiable evidence — e.g., sync job URLs, connection IDs tested]Option 2: PR Comment After adding your response, re-run Note: The Behavioral Changes gate is flagged as FAIL (WARNING) due to |
|
/ai-canary-prerelease
|
Canary Prerelease Testing — StartingStarting canary prerelease testing for Plan:
Session: https://app.devin.ai/sessions/c8150f32e6074617924d5a1515c673bf |
|
|
|
/publish-connectors-prerelease
|
|
|
Canary Prerelease: Status UpdateStatus: ⏸️ BLOCKED — Prerelease publish failing Breaking change gate: ✅ PASS — No schema/spec/state/stream changes. Behavioral-only fix (adds socket timeout to parent-stream HTTP sessions). Reversibility gate: ✅ PASS — No state format or config changes. Previous version handles rollback cleanly. Canary connections: 8 connections selected across 3 dataplanes (US, US-Central, EU) with 5 destination types (Snowflake, BigQuery, Chatwoot, Supabase, S3). HITL approval pending. Blocker: The pre-release publish workflow ( Failed runs: Next steps: I've escalated to |
|
/publish-connectors-prerelease
|
|
|
|
|
|
Canary Prerelease: Status Update (3h blocked)Status: ⏸️ BLOCKED — Prerelease publish failing (9 consecutive attempts over approximately 3 hours) Root cause: GitHub Actions snap store outage — All other canary phases are ready:
I've escalated to |
|
|
|
|
|
Canary Prerelease: BLOCKED Verdict (Interim)Connector: SummaryCanary testing is BLOCKED by a prolonged GitHub Actions infrastructure outage. The Phases Completed
Canary VerdictOverall Status: BLOCKED The prerelease Docker image Options to Unblock
Handoff: Canary Connection SetIf canary testing is resumed manually, the following 8 connections were selected (all TIER_2, all unpinned, all with recent successful syncs). Full details including workspace IDs, connection IDs, and actor IDs are available in the Devin session.
No connections were pinned — no rollback is needed. |
|
|
|
Canary Prerelease: Final ReportConnector: SummaryCanary testing could not be completed due to a prolonged GitHub Actions infrastructure outage. The snap store has been unreachable for 20+ hours (2026-05-01 13:00 UTC through 2026-05-02 08:18 UTC), preventing the Docker image from being built across 17 consecutive publish attempts. Canary VerdictOverall Status: BLOCKED No connections were pinned, no data risk was introduced, and no rollback is needed. What Was Completed
Recommended Next Steps
Canary Connection Set (for re-use)The following 8 connections were selected (all TIER_2, unpinned, recently active). Full details are in the Devin session.
|
|
Canary Prerelease: Status Update — UNBLOCKEDThe snap store outage has resolved and the prerelease Docker image HITL approval request sent to |
Canary Prerelease: Deployment CompleteAll 8 canary connections have been pinned to
Monitoring begins now. Next sync results check in approximately 1 hour. For full customer details, see the linked private issue. |
Canary Monitoring Update (2026-05-02 17:05 UTC)Monitoring duration: approximately 1 hour 20 minutes since pinning
Totals: 9 syncs observed | 8 succeeded | 0 failed | 1 running Overall status: HEALTHY — No failures detected. Next check in approximately 1 hour. |
Canary Prerelease: Final Report — PASS ✅Connector: Results Summary
Per-Connection Breakdown
Failure AnalysisThe single failure (Customer-D-US-Central-1, Supabase destination) was transient — the same actor succeeded on its very next sync. Cross-referencing with general VerdictPASS — The TimeoutHTTPAdapter fix ( Phase 2 Gates (from initial evaluation)
Next StepsConnections remain pinned to |
|
↪️ Re-triggering Reason: Previous |
Reviewing PR for connector safety and quality.
|
AI PR Review ReportReview Action: APPROVED
📋 PR DetailsConnector & PR InfoConnector(s): Risk LevelLevel: 4 — High Risk Level is reported for downstream consumers (e.g., auto-merge policy, reviewer routing). It does not change the review action — APPROVE here means "no blocking objection," not "safe to merge unattended." Review Action DetailsAPPROVED — All enforced gates pass (PR Hygiene, Test Coverage, Code Security, CI Checks, Live / E2E Tests). The single Anti-Pattern FAIL (Behavioral Changes) is a WARNING-level gate that surfaces in the report and elevates risk level but does not block APPROVE. This fixes a re-evaluation of the prior 🔍 Gate Evaluation DetailsGate-by-Gate Analysis
Notes on the failing
|
Anatolii Yatsuk (tolik0)
deleted the
devin/1777623443-google-ads-timeout-base-requester
branch
🧹 Canary Cleanup CompletePR has been merged. All 8 canary connections have been unpinned from
Canary testing lifecycle complete. No stale pins remain. Session: https://app.devin.ai/sessions/c8150f32e6074617924d5a1515c673bf |
3 participants
What
Closes a hole in PR #76074: the 5-minute HTTP socket timeout from
TimeoutHTTPAdapterwas only mounted on the data-stream requester (GoogleAdsHttpRequester) and the custom-GAQL requester (CustomGAQueryHttpRequester). It was not mounted on thebase_requesterused by parent streams (customer_client,customer_client_non_manager,accessible_accounts).Live evidence — job 82233624 on 4.2.6-rc.1:
queue_full=False(so not the queue-full deadlock fixed by CDK PR MSSQL Source #977 / shipped in 4.2.5).ssl.py:1166 read()inside arequests_cache.session._send_and_cachecall.substream_partition_router.stream_slicesiterating parent records ofcustomers_and_campaigns— i.e. acustomer_clientfetch, which routes throughbase_requester.Because
base_requesteris a stock CDKHttpRequesterwith no__post_init__override, noTimeoutHTTPAdapterwas ever mounted on its session and the socket read could block indefinitely. Same gap is present in 4.2.5 GA — this is not an rc.1 regression.How
Added a
_mount_timeout_adapter(requester)helper insource_google_ads/components.pythat mountsTimeoutHTTPAdapteron a requester's_http_client._sessionif one exists. Called from:GoogleAdsHttpRequester.__post_init__(replaces the existing inline mount)CustomGAQueryHttpRequester.__post_init__(replaces the existing inline mount)GoogleAdsRetriever.__post_init__— coversbase_retriever(used bycustomer_client,customer_client_non_manager,accessible_accounts) regardless of whether the requester is a custom subclass or the stockHttpRequesterCriterionRetriever.__post_init__— same treatment for criterion streamsMount is idempotent (
session.mount("https://", ...)replaces any existing prefix adapter), so streams whose requester already mounted the adapter via its own__post_init__are unaffected.Bumped to
4.2.6-rc.2and added a changelog entry.Review guide
airbyte-integrations/connectors/source-google-ads/source_google_ads/components.py— new_mount_timeout_adapterhelper, four call sitesairbyte-integrations/connectors/source-google-ads/metadata.yamlandpyproject.toml— version bump to 4.2.6-rc.2docs/integrations/sources/google-ads.md— changelog entryUser Impact
Parent-stream HTTP calls now have the same 5-minute socket-level idle timeout as data-stream calls. A hung Google Ads API response on a parent fetch will now fail and be retried instead of stalling the worker for >4 hours and tripping the platform's heartbeat reaper.
No spec / schema / state changes. No expected user-visible behavior change other than fewer heartbeat-timeout failures on the parent-stream code path.
Can this PR be safely reverted and rolled back?
Link to Devin session: https://app.devin.ai/sessions/bc28bf62dcc3400ca2906b3131b84394