Repository navigation
Apply hook_params to deferred dbt Cloud job runs - #74199
Merged
josh-fell merged 1 commit intoOct 6, 2026
Merged
Conversation
DbtCloudRunJobOperator accepts hook_params, documented as extra arguments for the DbtCloudHook constructor, and uses them on the worker. It did not hand them to the trigger it defers to, so the triggerer built its hook without them and a configured retry limit or delay was silently ignored once the task deferred. DbtCloudRunJobTrigger has accepted, serialized and used hook_params since the sensor started passing them, so only the operator's call site was missing.
josh-fell
approved these changes
Oct 6, 2026
1 task done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DbtCloudRunJobOperatoracceptshook_params, documented as "Extra arguments passed to the DbtCloudHook constructor", and applies them on the worker: itshookproperty isDbtCloudHook(self.dbt_cloud_conn_id, **self.hook_params). When the operator defers, it did not pass them toDbtCloudRunJobTrigger, so the triggerer built its hook asDbtCloudHook(self.conn_id)with the defaults. A configuredretry_limitorretry_delayapplied before the task deferred and was silently ignored afterwards.The trigger has needed no change: it already accepts
hook_params, keeps it across serialization, and uses it when it builds the hook.DbtCloudJobRunSensoralready passes it, since #57242 addedhook_paramsto the sensor to align it with the operators in this provider. That left the operator's own deferred path as the one call site still dropping it, which is what this changes.Tests
A new test asserts the trigger receives the operator's
hook_params. It fails without the one-line change.It is worth being explicit that this also modifies an existing test.
test_execute_deferrable_does_not_pass_execution_timeout_to_deferpins the trigger's complete keyword set withassert_called_once_with, so adding an argument necessarily changes it. The edit addshook_params={}, which is what the operator's default produces. That test also fails against the unpatched operator, so the assertion is pinned to the new behaviour rather than relaxed to accommodate it.Also run: the full
providers/dbt/cloudsuite (288 passed) and mypy.On a changelog entry
I have not added one. The parameter was always documented as reaching the hook, so this makes the documented behaviour true rather than changing a contract, and a reviewer on a sibling PR of mine noted that a changelog entry for this kind of bugfix is debatable. Happy to add one if you would rather have it.
No existing issue; opening the PR directly rather than filing one first.
Was generative AI tooling used to co-author this PR?