-
Notifications
You must be signed in to change notification settings - Fork 16.3k
Fix Google Cloud Data Fusion hook to handle pipeline start errors properly #58698
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Google Cloud Data Fusion hook to handle pipeline start errors properly #58698
Conversation
providers/google/tests/unit/google/cloud/hooks/test_datafusion.py
Outdated
Show resolved
Hide resolved
providers/google/tests/unit/google/cloud/hooks/test_datafusion.py
Outdated
Show resolved
Hide resolved
|
hi there! thank you for the fix. Can please also provide the screenshot of the green system tests running in Airflow UI? |
|
@VladaZakharova Thank you for the feedback! I've verified the fix works correctly with all 45 unit tests passing, including a new test specifically for the error case ( Running the full system tests requires setting up and provisioning a Data Fusion instance. Given that the unit tests comprehensively cover the fix (switching from multi-program to single-program endpoint + runId validation), I believe they provide sufficient verification. However, if you'd like me to set up and run the full system tests, I'm happy to do so. |
If you're able to run the system tests on your side and provide some screenshots, we'll be happy if you could do so. |
|
@shahar1 @VladaZakharova if you can, that will be great. |
…perly The start_pipeline method was using the multi-program start endpoint which returns HTTP 200 even when individual programs fail to start. This caused a KeyError when trying to access the runId from error responses. Changes: - Updated start_pipeline to use single-program start endpoint - Added validation to check if runId exists in response before accessing it - Improved error messages to provide context about failures - Updated tests to reflect new endpoint and added test for missing runId scenario Fixes apache#50387
975a6f7 to
0669841
Compare
…perly (apache#58698) * Fix Google Cloud Data Fusion hook to handle pipeline start errors properly The start_pipeline method was using the multi-program start endpoint which returns HTTP 200 even when individual programs fail to start. This caused a KeyError when trying to access the runId from error responses. Changes: - Updated start_pipeline to use single-program start endpoint - Added validation to check if runId exists in response before accessing it - Improved error messages to provide context about failures - Updated tests to reflect new endpoint and added test for missing runId scenario Fixes apache#50387 * Add spec to MagicMock for better static type checking
…perly (apache#58698) * Fix Google Cloud Data Fusion hook to handle pipeline start errors properly The start_pipeline method was using the multi-program start endpoint which returns HTTP 200 even when individual programs fail to start. This caused a KeyError when trying to access the runId from error responses. Changes: - Updated start_pipeline to use single-program start endpoint - Added validation to check if runId exists in response before accessing it - Improved error messages to provide context about failures - Updated tests to reflect new endpoint and added test for missing runId scenario Fixes apache#50387 * Add spec to MagicMock for better static type checking
…rors properly (apache#58698)" This reverts commit a4f2b33.
Description
Fixes #50387 - Bug in Data Fusion hook where
start_pipelinecrashes withKeyError: 'runId'when pipelines fail to start.Problem
The hook used the multi-program start endpoint which returns HTTP 200 even on failures. The code accessed
response_json[0]["runId"]without validation, causing a KeyError when the field was missing.Solution
POST .../apps/{app}/{program-type}s/{program-id}/startrunIdexists in response before accessingChanges
Updated
start_pipelinemethod to use correct CDAP endpoint and added response validation.Breaking Changes
None - method signature and return type unchanged. Only the internal API endpoint changed.
Testing