Fix Google Cloud Data Fusion hook to handle pipeline start errors properly#58698
Conversation
|
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.
…rors properly (apache#58698)" (apache#60701) This reverts commit a4f2b33.
…rors properly (apache#58698)" (apache#60701) This reverts commit a4f2b33.
…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)" (apache#60701) This reverts commit a4f2b33.
…rors properly (apache#58698)" (apache#60701) This reverts commit a4f2b33.
…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)" (apache#60701) This reverts commit a4f2b33.
…rors properly (apache#58698)" (apache#60701) 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