Fix DbtCloudRunJobTrigger timeout error message and add final status check by eran-moses-human · Pull Request #61980 · apache/airflow

eran-moses-human · 2026-02-16T07:07:17Z

Summary

Fixes two bugs in DbtCloudRunJobTrigger.run():

Misleading error message: The timeout message printed self.end_time (an absolute epoch timestamp, e.g. 1771200015.8) labelled as "seconds", producing nonsensical output. Replaced with a clear "within the configured timeout" message.
Missing final status check: The timeout check fired without re-polling the job status. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Now performs one final is_still_running() call before yielding a timeout error.

Changes

providers/dbt/cloud/src/airflow/providers/dbt/cloud/triggers/dbt.py:
- Moved asyncio.sleep() before the timeout check
- Added a final is_still_running() call when the timeout fires
- Fixed the error message to no longer print epoch timestamp as duration
providers/dbt/cloud/tests/unit/dbt/cloud/triggers/test_dbt.py:
- Updated existing timeout test to match new error message
- Added new test test_dbt_job_run_timeout_but_job_completes for the edge case where a job completes at the timeout boundary

Closes#61979

Made with Cursor

…check The timeout error message in DbtCloudRunJobTrigger.run() printed self.end_time (an absolute epoch timestamp) labelled as "seconds", producing nonsensical output like "after 1771200015.8 seconds" instead of a meaningful duration. Additionally, the timeout check fired before sleeping, without a final status poll. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Changes: - Move asyncio.sleep() before the timeout check so the trigger sleeps first, then evaluates the deadline. - Add a final is_still_running() call when the timeout fires so that jobs completing at the boundary are handled correctly. - Replace the misleading epoch-as-duration message with a clear "within the configured timeout" message. - Update existing timeout test and add a new test for the edge case where a job completes at the timeout boundary. Closes: apache#61979 Co-authored-by: Cursor <cursoragent@cursor.com>

boring-cyborg · 2026-02-16T07:07:27Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

SameerMesiah97

Looks good. I would fix the CI failures (one looks unrelated but the other prek related which you can fix).

Just a heads up: you might get conflicts if PR #61472 merges first as it is touching the same lines of code.

SameerMesiah97 · 2026-02-16T22:33:21Z

+ )
+ return
+ # Job reached a terminal state — exit loop to handle below.
+ break


It looks like the timeout emission could be extended by poll_interval, meaning the actual timeout could occur up to one full polling cycle later than the configured value. For example, with timeout=60s and poll_interval=30s, the timeout may not be emitted until around 90s depending on scheduling.
I believe this behavior was already present prior to this PR, so it’s not a regression. That said, we might consider sleeping for min(poll_interval, remaining_time) to align the timeout more closely with the configured value. This should not block the PR, but I think it might be worth exploring.

SameerMesiah97 · 2026-02-16T22:45:13Z

+ async def test_dbt_job_run_timeout_but_job_completes(
+ self, mock_get_job_status, mocked_is_still_running
+ ):
+ """Assert that a job completing at the timeout boundary is treated as success, not timeout."""


Nit: the docstring mentions "completing at the timeout boundary", but the test appears to simulate completion after the deadline has technically passed but before timeout emission. I would suggest clarifying it accordingly.

josh-fell · 2026-02-27T15:27:33Z

@eran-moses-human There are some merge conflicts now. Can you resolve and re-push when you get a chance?

josh-fell · 2026-03-11T17:15:17Z

@eran-moses-human Can you resolve conflicts here please when you get a chance?

potiuk · 2026-03-12T01:01:05Z

@eran-moses-human This PR has been converted to draft because it does not yet meet our Pull Request quality criteria.

Issues found:

❌ Merge conflicts: This PR has merge conflicts with the main branch. Your branch is 707 commits behind main. Please rebase your branch (git fetch origin && git rebase origin/main), resolve the conflicts, and push again. See contributing quick start.
❌ Unit tests: Failing: Basic tests / Breeze unit tests. Run failing tests with breeze run pytest <path> -xvs. See Unit tests docs.
❌ Pre-commit / static checks: Failing: CI image checks / Static checks. Run prek run --from-ref main locally to find and fix issues. See Pre-commit / static checks docs.

Note: Your branch is 707 commits behind main. Some check failures may be caused by changes in the base branch rather than by your PR. Please rebase your branch and push again to get up-to-date CI results.

What to do next:

The comment informs you what you need to do.
Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
Maintainers will then proceed with a normal review.

Converting a PR to draft is not a rejection — it is an invitation to bring the PR up to the project's standards so that maintainer review time is spent productively. If you have questions, feel free to ask on the Airflow Slack.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

josh-fell · 2026-03-12T01:28:17Z

@potiuk First of all, long-time, no talk; love the new automation as usual. One minor nit in the suggestion to resolve the merge conflicts:

Please rebase your branch (git fetch origin && git rebase origin/main),

Should be git fetch upstream && git rebase origin/main and/or link to the "How to rebase PR" docs, since folks are working with forks, I think?

potiuk · 2026-04-02T17:08:07Z

This pull request has been converted to draft due to quality issues more than a week ago and there has been no response from the author.

@eran-moses-human, you are welcome to reopen this PR when you are ready to continue working on it. Thank you for your contribution!

eran-moses-human · 2026-02-16T07:07:17Z

Summary

Fixes two bugs in DbtCloudRunJobTrigger.run():

Misleading error message: The timeout message printed self.end_time (an absolute epoch timestamp, e.g. 1771200015.8) labelled as "seconds", producing nonsensical output. Replaced with a clear "within the configured timeout" message.
Missing final status check: The timeout check fired without re-polling the job status. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Now performs one final is_still_running() call before yielding a timeout error.

Changes

providers/dbt/cloud/src/airflow/providers/dbt/cloud/triggers/dbt.py:
- Moved asyncio.sleep() before the timeout check
- Added a final is_still_running() call when the timeout fires
- Fixed the error message to no longer print epoch timestamp as duration
providers/dbt/cloud/tests/unit/dbt/cloud/triggers/test_dbt.py:
- Updated existing timeout test to match new error message
- Added new test test_dbt_job_run_timeout_but_job_completes for the edge case where a job completes at the timeout boundary

Closes#61979

Made with Cursor

…check The timeout error message in DbtCloudRunJobTrigger.run() printed self.end_time (an absolute epoch timestamp) labelled as "seconds", producing nonsensical output like "after 1771200015.8 seconds" instead of a meaningful duration. Additionally, the timeout check fired before sleeping, without a final status poll. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Changes: - Move asyncio.sleep() before the timeout check so the trigger sleeps first, then evaluates the deadline. - Add a final is_still_running() call when the timeout fires so that jobs completing at the boundary are handled correctly. - Replace the misleading epoch-as-duration message with a clear "within the configured timeout" message. - Update existing timeout test and add a new test for the edge case where a job completes at the timeout boundary. Closes: apache#61979 Co-authored-by: Cursor <cursoragent@cursor.com>

boring-cyborg · 2026-02-16T07:07:27Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

SameerMesiah97

Looks good. I would fix the CI failures (one looks unrelated but the other prek related which you can fix).

Just a heads up: you might get conflicts if PR #61472 merges first as it is touching the same lines of code.

SameerMesiah97 · 2026-02-16T22:33:21Z

+ )
+ return
+ # Job reached a terminal state — exit loop to handle below.
+ break


It looks like the timeout emission could be extended by poll_interval, meaning the actual timeout could occur up to one full polling cycle later than the configured value. For example, with timeout=60s and poll_interval=30s, the timeout may not be emitted until around 90s depending on scheduling.
I believe this behavior was already present prior to this PR, so it’s not a regression. That said, we might consider sleeping for min(poll_interval, remaining_time) to align the timeout more closely with the configured value. This should not block the PR, but I think it might be worth exploring.

SameerMesiah97 · 2026-02-16T22:45:13Z

+ async def test_dbt_job_run_timeout_but_job_completes(
+ self, mock_get_job_status, mocked_is_still_running
+ ):
+ """Assert that a job completing at the timeout boundary is treated as success, not timeout."""


Nit: the docstring mentions "completing at the timeout boundary", but the test appears to simulate completion after the deadline has technically passed but before timeout emission. I would suggest clarifying it accordingly.

josh-fell · 2026-02-27T15:27:33Z

@eran-moses-human There are some merge conflicts now. Can you resolve and re-push when you get a chance?

josh-fell · 2026-03-11T17:15:17Z

@eran-moses-human Can you resolve conflicts here please when you get a chance?

potiuk · 2026-03-12T01:01:05Z

@eran-moses-human This PR has been converted to draft because it does not yet meet our Pull Request quality criteria.

Issues found:

❌ Merge conflicts: This PR has merge conflicts with the main branch. Your branch is 707 commits behind main. Please rebase your branch (git fetch origin && git rebase origin/main), resolve the conflicts, and push again. See contributing quick start.
❌ Unit tests: Failing: Basic tests / Breeze unit tests. Run failing tests with breeze run pytest <path> -xvs. See Unit tests docs.
❌ Pre-commit / static checks: Failing: CI image checks / Static checks. Run prek run --from-ref main locally to find and fix issues. See Pre-commit / static checks docs.

Note: Your branch is 707 commits behind main. Some check failures may be caused by changes in the base branch rather than by your PR. Please rebase your branch and push again to get up-to-date CI results.

What to do next:

The comment informs you what you need to do.
Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
Maintainers will then proceed with a normal review.

Converting a PR to draft is not a rejection — it is an invitation to bring the PR up to the project's standards so that maintainer review time is spent productively. If you have questions, feel free to ask on the Airflow Slack.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

josh-fell · 2026-03-12T01:28:17Z

@potiuk First of all, long-time, no talk; love the new automation as usual. One minor nit in the suggestion to resolve the merge conflicts:

Please rebase your branch (git fetch origin && git rebase origin/main),

Should be git fetch upstream && git rebase origin/main and/or link to the "How to rebase PR" docs, since folks are working with forks, I think?

potiuk · 2026-04-02T17:08:07Z

This pull request has been converted to draft due to quality issues more than a week ago and there has been no response from the author.

@eran-moses-human, you are welcome to reopen this PR when you are ready to continue working on it. Thank you for your contribution!

eran-moses-human · 2026-02-16T07:07:17Z

Summary

Fixes two bugs in DbtCloudRunJobTrigger.run():

Misleading error message: The timeout message printed self.end_time (an absolute epoch timestamp, e.g. 1771200015.8) labelled as "seconds", producing nonsensical output. Replaced with a clear "within the configured timeout" message.
Missing final status check: The timeout check fired without re-polling the job status. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Now performs one final is_still_running() call before yielding a timeout error.

Changes

providers/dbt/cloud/src/airflow/providers/dbt/cloud/triggers/dbt.py:
- Moved asyncio.sleep() before the timeout check
- Added a final is_still_running() call when the timeout fires
- Fixed the error message to no longer print epoch timestamp as duration
providers/dbt/cloud/tests/unit/dbt/cloud/triggers/test_dbt.py:
- Updated existing timeout test to match new error message
- Added new test test_dbt_job_run_timeout_but_job_completes for the edge case where a job completes at the timeout boundary

Closes#61979

Made with Cursor

…check The timeout error message in DbtCloudRunJobTrigger.run() printed self.end_time (an absolute epoch timestamp) labelled as "seconds", producing nonsensical output like "after 1771200015.8 seconds" instead of a meaningful duration. Additionally, the timeout check fired before sleeping, without a final status poll. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Changes: - Move asyncio.sleep() before the timeout check so the trigger sleeps first, then evaluates the deadline. - Add a final is_still_running() call when the timeout fires so that jobs completing at the boundary are handled correctly. - Replace the misleading epoch-as-duration message with a clear "within the configured timeout" message. - Update existing timeout test and add a new test for the edge case where a job completes at the timeout boundary. Closes: apache#61979 Co-authored-by: Cursor <cursoragent@cursor.com>

boring-cyborg · 2026-02-16T07:07:27Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

SameerMesiah97

Looks good. I would fix the CI failures (one looks unrelated but the other prek related which you can fix).

Just a heads up: you might get conflicts if PR #61472 merges first as it is touching the same lines of code.

SameerMesiah97 · 2026-02-16T22:33:21Z

+ )
+ return
+ # Job reached a terminal state — exit loop to handle below.
+ break


It looks like the timeout emission could be extended by poll_interval, meaning the actual timeout could occur up to one full polling cycle later than the configured value. For example, with timeout=60s and poll_interval=30s, the timeout may not be emitted until around 90s depending on scheduling.
I believe this behavior was already present prior to this PR, so it’s not a regression. That said, we might consider sleeping for min(poll_interval, remaining_time) to align the timeout more closely with the configured value. This should not block the PR, but I think it might be worth exploring.

SameerMesiah97 · 2026-02-16T22:45:13Z

+ async def test_dbt_job_run_timeout_but_job_completes(
+ self, mock_get_job_status, mocked_is_still_running
+ ):
+ """Assert that a job completing at the timeout boundary is treated as success, not timeout."""


Nit: the docstring mentions "completing at the timeout boundary", but the test appears to simulate completion after the deadline has technically passed but before timeout emission. I would suggest clarifying it accordingly.

josh-fell · 2026-02-27T15:27:33Z

@eran-moses-human There are some merge conflicts now. Can you resolve and re-push when you get a chance?

josh-fell · 2026-03-11T17:15:17Z

@eran-moses-human Can you resolve conflicts here please when you get a chance?

potiuk · 2026-03-12T01:01:05Z

@eran-moses-human This PR has been converted to draft because it does not yet meet our Pull Request quality criteria.

Issues found:

❌ Merge conflicts: This PR has merge conflicts with the main branch. Your branch is 707 commits behind main. Please rebase your branch (git fetch origin && git rebase origin/main), resolve the conflicts, and push again. See contributing quick start.
❌ Unit tests: Failing: Basic tests / Breeze unit tests. Run failing tests with breeze run pytest <path> -xvs. See Unit tests docs.
❌ Pre-commit / static checks: Failing: CI image checks / Static checks. Run prek run --from-ref main locally to find and fix issues. See Pre-commit / static checks docs.

Note: Your branch is 707 commits behind main. Some check failures may be caused by changes in the base branch rather than by your PR. Please rebase your branch and push again to get up-to-date CI results.

What to do next:

The comment informs you what you need to do.
Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
Maintainers will then proceed with a normal review.

Converting a PR to draft is not a rejection — it is an invitation to bring the PR up to the project's standards so that maintainer review time is spent productively. If you have questions, feel free to ask on the Airflow Slack.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

josh-fell · 2026-03-12T01:28:17Z

@potiuk First of all, long-time, no talk; love the new automation as usual. One minor nit in the suggestion to resolve the merge conflicts:

Please rebase your branch (git fetch origin && git rebase origin/main),

Should be git fetch upstream && git rebase origin/main and/or link to the "How to rebase PR" docs, since folks are working with forks, I think?

potiuk · 2026-04-02T17:08:07Z

This pull request has been converted to draft due to quality issues more than a week ago and there has been no response from the author.

@eran-moses-human, you are welcome to reopen this PR when you are ready to continue working on it. Thank you for your contribution!

eran-moses-human · 2026-02-16T07:07:17Z

Summary

Fixes two bugs in DbtCloudRunJobTrigger.run():

Misleading error message: The timeout message printed self.end_time (an absolute epoch timestamp, e.g. 1771200015.8) labelled as "seconds", producing nonsensical output. Replaced with a clear "within the configured timeout" message.
Missing final status check: The timeout check fired without re-polling the job status. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Now performs one final is_still_running() call before yielding a timeout error.

Changes

providers/dbt/cloud/src/airflow/providers/dbt/cloud/triggers/dbt.py:
- Moved asyncio.sleep() before the timeout check
- Added a final is_still_running() call when the timeout fires
- Fixed the error message to no longer print epoch timestamp as duration
providers/dbt/cloud/tests/unit/dbt/cloud/triggers/test_dbt.py:
- Updated existing timeout test to match new error message
- Added new test test_dbt_job_run_timeout_but_job_completes for the edge case where a job completes at the timeout boundary

Closes#61979

Made with Cursor

…check The timeout error message in DbtCloudRunJobTrigger.run() printed self.end_time (an absolute epoch timestamp) labelled as "seconds", producing nonsensical output like "after 1771200015.8 seconds" instead of a meaningful duration. Additionally, the timeout check fired before sleeping, without a final status poll. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Changes: - Move asyncio.sleep() before the timeout check so the trigger sleeps first, then evaluates the deadline. - Add a final is_still_running() call when the timeout fires so that jobs completing at the boundary are handled correctly. - Replace the misleading epoch-as-duration message with a clear "within the configured timeout" message. - Update existing timeout test and add a new test for the edge case where a job completes at the timeout boundary. Closes: apache#61979 Co-authored-by: Cursor <cursoragent@cursor.com>

boring-cyborg · 2026-02-16T07:07:27Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

SameerMesiah97

Looks good. I would fix the CI failures (one looks unrelated but the other prek related which you can fix).

Just a heads up: you might get conflicts if PR #61472 merges first as it is touching the same lines of code.

SameerMesiah97 · 2026-02-16T22:33:21Z

+ )
+ return
+ # Job reached a terminal state — exit loop to handle below.
+ break


It looks like the timeout emission could be extended by poll_interval, meaning the actual timeout could occur up to one full polling cycle later than the configured value. For example, with timeout=60s and poll_interval=30s, the timeout may not be emitted until around 90s depending on scheduling.
I believe this behavior was already present prior to this PR, so it’s not a regression. That said, we might consider sleeping for min(poll_interval, remaining_time) to align the timeout more closely with the configured value. This should not block the PR, but I think it might be worth exploring.

SameerMesiah97 · 2026-02-16T22:45:13Z

+ async def test_dbt_job_run_timeout_but_job_completes(
+ self, mock_get_job_status, mocked_is_still_running
+ ):
+ """Assert that a job completing at the timeout boundary is treated as success, not timeout."""


Nit: the docstring mentions "completing at the timeout boundary", but the test appears to simulate completion after the deadline has technically passed but before timeout emission. I would suggest clarifying it accordingly.

josh-fell · 2026-02-27T15:27:33Z

@eran-moses-human There are some merge conflicts now. Can you resolve and re-push when you get a chance?

josh-fell · 2026-03-11T17:15:17Z

@eran-moses-human Can you resolve conflicts here please when you get a chance?

potiuk · 2026-03-12T01:01:05Z

@eran-moses-human This PR has been converted to draft because it does not yet meet our Pull Request quality criteria.

Issues found:

❌ Merge conflicts: This PR has merge conflicts with the main branch. Your branch is 707 commits behind main. Please rebase your branch (git fetch origin && git rebase origin/main), resolve the conflicts, and push again. See contributing quick start.
❌ Unit tests: Failing: Basic tests / Breeze unit tests. Run failing tests with breeze run pytest <path> -xvs. See Unit tests docs.
❌ Pre-commit / static checks: Failing: CI image checks / Static checks. Run prek run --from-ref main locally to find and fix issues. See Pre-commit / static checks docs.

Note: Your branch is 707 commits behind main. Some check failures may be caused by changes in the base branch rather than by your PR. Please rebase your branch and push again to get up-to-date CI results.

What to do next:

The comment informs you what you need to do.
Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
Maintainers will then proceed with a normal review.

Converting a PR to draft is not a rejection — it is an invitation to bring the PR up to the project's standards so that maintainer review time is spent productively. If you have questions, feel free to ask on the Airflow Slack.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

josh-fell · 2026-03-12T01:28:17Z

@potiuk First of all, long-time, no talk; love the new automation as usual. One minor nit in the suggestion to resolve the merge conflicts:

Please rebase your branch (git fetch origin && git rebase origin/main),

Should be git fetch upstream && git rebase origin/main and/or link to the "How to rebase PR" docs, since folks are working with forks, I think?

potiuk · 2026-04-02T17:08:07Z

This pull request has been converted to draft due to quality issues more than a week ago and there has been no response from the author.

@eran-moses-human, you are welcome to reopen this PR when you are ready to continue working on it. Thank you for your contribution!

eran-moses-human · 2026-02-16T07:07:17Z

Summary

Fixes two bugs in DbtCloudRunJobTrigger.run():

Misleading error message: The timeout message printed self.end_time (an absolute epoch timestamp, e.g. 1771200015.8) labelled as "seconds", producing nonsensical output. Replaced with a clear "within the configured timeout" message.
Missing final status check: The timeout check fired without re-polling the job status. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Now performs one final is_still_running() call before yielding a timeout error.

Changes

providers/dbt/cloud/src/airflow/providers/dbt/cloud/triggers/dbt.py:
- Moved asyncio.sleep() before the timeout check
- Added a final is_still_running() call when the timeout fires
- Fixed the error message to no longer print epoch timestamp as duration
providers/dbt/cloud/tests/unit/dbt/cloud/triggers/test_dbt.py:
- Updated existing timeout test to match new error message
- Added new test test_dbt_job_run_timeout_but_job_completes for the edge case where a job completes at the timeout boundary

Closes#61979

Made with Cursor

…check The timeout error message in DbtCloudRunJobTrigger.run() printed self.end_time (an absolute epoch timestamp) labelled as "seconds", producing nonsensical output like "after 1771200015.8 seconds" instead of a meaningful duration. Additionally, the timeout check fired before sleeping, without a final status poll. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Changes: - Move asyncio.sleep() before the timeout check so the trigger sleeps first, then evaluates the deadline. - Add a final is_still_running() call when the timeout fires so that jobs completing at the boundary are handled correctly. - Replace the misleading epoch-as-duration message with a clear "within the configured timeout" message. - Update existing timeout test and add a new test for the edge case where a job completes at the timeout boundary. Closes: apache#61979 Co-authored-by: Cursor <cursoragent@cursor.com>

boring-cyborg · 2026-02-16T07:07:27Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

SameerMesiah97

Looks good. I would fix the CI failures (one looks unrelated but the other prek related which you can fix).

Just a heads up: you might get conflicts if PR #61472 merges first as it is touching the same lines of code.

SameerMesiah97 · 2026-02-16T22:33:21Z

+ )
+ return
+ # Job reached a terminal state — exit loop to handle below.
+ break


It looks like the timeout emission could be extended by poll_interval, meaning the actual timeout could occur up to one full polling cycle later than the configured value. For example, with timeout=60s and poll_interval=30s, the timeout may not be emitted until around 90s depending on scheduling.
I believe this behavior was already present prior to this PR, so it’s not a regression. That said, we might consider sleeping for min(poll_interval, remaining_time) to align the timeout more closely with the configured value. This should not block the PR, but I think it might be worth exploring.

SameerMesiah97 · 2026-02-16T22:45:13Z

+ async def test_dbt_job_run_timeout_but_job_completes(
+ self, mock_get_job_status, mocked_is_still_running
+ ):
+ """Assert that a job completing at the timeout boundary is treated as success, not timeout."""


Nit: the docstring mentions "completing at the timeout boundary", but the test appears to simulate completion after the deadline has technically passed but before timeout emission. I would suggest clarifying it accordingly.

josh-fell · 2026-02-27T15:27:33Z

@eran-moses-human There are some merge conflicts now. Can you resolve and re-push when you get a chance?

josh-fell · 2026-03-11T17:15:17Z

@eran-moses-human Can you resolve conflicts here please when you get a chance?

potiuk · 2026-03-12T01:01:05Z

@eran-moses-human This PR has been converted to draft because it does not yet meet our Pull Request quality criteria.

Issues found:

❌ Merge conflicts: This PR has merge conflicts with the main branch. Your branch is 707 commits behind main. Please rebase your branch (git fetch origin && git rebase origin/main), resolve the conflicts, and push again. See contributing quick start.
❌ Unit tests: Failing: Basic tests / Breeze unit tests. Run failing tests with breeze run pytest <path> -xvs. See Unit tests docs.
❌ Pre-commit / static checks: Failing: CI image checks / Static checks. Run prek run --from-ref main locally to find and fix issues. See Pre-commit / static checks docs.

Note: Your branch is 707 commits behind main. Some check failures may be caused by changes in the base branch rather than by your PR. Please rebase your branch and push again to get up-to-date CI results.

What to do next:

The comment informs you what you need to do.
Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
Maintainers will then proceed with a normal review.

Converting a PR to draft is not a rejection — it is an invitation to bring the PR up to the project's standards so that maintainer review time is spent productively. If you have questions, feel free to ask on the Airflow Slack.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

josh-fell · 2026-03-12T01:28:17Z

@potiuk First of all, long-time, no talk; love the new automation as usual. One minor nit in the suggestion to resolve the merge conflicts:

Please rebase your branch (git fetch origin && git rebase origin/main),

Should be git fetch upstream && git rebase origin/main and/or link to the "How to rebase PR" docs, since folks are working with forks, I think?

potiuk · 2026-04-02T17:08:07Z

This pull request has been converted to draft due to quality issues more than a week ago and there has been no response from the author.

@eran-moses-human, you are welcome to reopen this PR when you are ready to continue working on it. Thank you for your contribution!

eran-moses-human · 2026-02-16T07:07:17Z

Summary

Fixes two bugs in DbtCloudRunJobTrigger.run():

Misleading error message: The timeout message printed self.end_time (an absolute epoch timestamp, e.g. 1771200015.8) labelled as "seconds", producing nonsensical output. Replaced with a clear "within the configured timeout" message.
Missing final status check: The timeout check fired without re-polling the job status. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Now performs one final is_still_running() call before yielding a timeout error.

Changes

providers/dbt/cloud/src/airflow/providers/dbt/cloud/triggers/dbt.py:
- Moved asyncio.sleep() before the timeout check
- Added a final is_still_running() call when the timeout fires
- Fixed the error message to no longer print epoch timestamp as duration
providers/dbt/cloud/tests/unit/dbt/cloud/triggers/test_dbt.py:
- Updated existing timeout test to match new error message
- Added new test test_dbt_job_run_timeout_but_job_completes for the edge case where a job completes at the timeout boundary

Closes#61979

Made with Cursor

…check The timeout error message in DbtCloudRunJobTrigger.run() printed self.end_time (an absolute epoch timestamp) labelled as "seconds", producing nonsensical output like "after 1771200015.8 seconds" instead of a meaningful duration. Additionally, the timeout check fired before sleeping, without a final status poll. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Changes: - Move asyncio.sleep() before the timeout check so the trigger sleeps first, then evaluates the deadline. - Add a final is_still_running() call when the timeout fires so that jobs completing at the boundary are handled correctly. - Replace the misleading epoch-as-duration message with a clear "within the configured timeout" message. - Update existing timeout test and add a new test for the edge case where a job completes at the timeout boundary. Closes: apache#61979 Co-authored-by: Cursor <cursoragent@cursor.com>

boring-cyborg · 2026-02-16T07:07:27Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

SameerMesiah97

Looks good. I would fix the CI failures (one looks unrelated but the other prek related which you can fix).

Just a heads up: you might get conflicts if PR #61472 merges first as it is touching the same lines of code.

SameerMesiah97 · 2026-02-16T22:33:21Z

+ )
+ return
+ # Job reached a terminal state — exit loop to handle below.
+ break


It looks like the timeout emission could be extended by poll_interval, meaning the actual timeout could occur up to one full polling cycle later than the configured value. For example, with timeout=60s and poll_interval=30s, the timeout may not be emitted until around 90s depending on scheduling.
I believe this behavior was already present prior to this PR, so it’s not a regression. That said, we might consider sleeping for min(poll_interval, remaining_time) to align the timeout more closely with the configured value. This should not block the PR, but I think it might be worth exploring.

SameerMesiah97 · 2026-02-16T22:45:13Z

+ async def test_dbt_job_run_timeout_but_job_completes(
+ self, mock_get_job_status, mocked_is_still_running
+ ):
+ """Assert that a job completing at the timeout boundary is treated as success, not timeout."""


Nit: the docstring mentions "completing at the timeout boundary", but the test appears to simulate completion after the deadline has technically passed but before timeout emission. I would suggest clarifying it accordingly.

josh-fell · 2026-02-27T15:27:33Z

@eran-moses-human There are some merge conflicts now. Can you resolve and re-push when you get a chance?

josh-fell · 2026-03-11T17:15:17Z

@eran-moses-human Can you resolve conflicts here please when you get a chance?

potiuk · 2026-03-12T01:01:05Z

@eran-moses-human This PR has been converted to draft because it does not yet meet our Pull Request quality criteria.

Issues found:

❌ Merge conflicts: This PR has merge conflicts with the main branch. Your branch is 707 commits behind main. Please rebase your branch (git fetch origin && git rebase origin/main), resolve the conflicts, and push again. See contributing quick start.
❌ Unit tests: Failing: Basic tests / Breeze unit tests. Run failing tests with breeze run pytest <path> -xvs. See Unit tests docs.
❌ Pre-commit / static checks: Failing: CI image checks / Static checks. Run prek run --from-ref main locally to find and fix issues. See Pre-commit / static checks docs.

Note: Your branch is 707 commits behind main. Some check failures may be caused by changes in the base branch rather than by your PR. Please rebase your branch and push again to get up-to-date CI results.

What to do next:

The comment informs you what you need to do.
Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
Maintainers will then proceed with a normal review.

Converting a PR to draft is not a rejection — it is an invitation to bring the PR up to the project's standards so that maintainer review time is spent productively. If you have questions, feel free to ask on the Airflow Slack.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

josh-fell · 2026-03-12T01:28:17Z

@potiuk First of all, long-time, no talk; love the new automation as usual. One minor nit in the suggestion to resolve the merge conflicts:

Please rebase your branch (git fetch origin && git rebase origin/main),

Should be git fetch upstream && git rebase origin/main and/or link to the "How to rebase PR" docs, since folks are working with forks, I think?

potiuk · 2026-04-02T17:08:07Z

This pull request has been converted to draft due to quality issues more than a week ago and there has been no response from the author.

@eran-moses-human, you are welcome to reopen this PR when you are ready to continue working on it. Thank you for your contribution!

eran-moses-human · 2026-02-16T07:07:17Z

Summary

Fixes two bugs in DbtCloudRunJobTrigger.run():

Misleading error message: The timeout message printed self.end_time (an absolute epoch timestamp, e.g. 1771200015.8) labelled as "seconds", producing nonsensical output. Replaced with a clear "within the configured timeout" message.
Missing final status check: The timeout check fired without re-polling the job status. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Now performs one final is_still_running() call before yielding a timeout error.

Changes

providers/dbt/cloud/src/airflow/providers/dbt/cloud/triggers/dbt.py:
- Moved asyncio.sleep() before the timeout check
- Added a final is_still_running() call when the timeout fires
- Fixed the error message to no longer print epoch timestamp as duration
providers/dbt/cloud/tests/unit/dbt/cloud/triggers/test_dbt.py:
- Updated existing timeout test to match new error message
- Added new test test_dbt_job_run_timeout_but_job_completes for the edge case where a job completes at the timeout boundary

Closes#61979

Made with Cursor

…check The timeout error message in DbtCloudRunJobTrigger.run() printed self.end_time (an absolute epoch timestamp) labelled as "seconds", producing nonsensical output like "after 1771200015.8 seconds" instead of a meaningful duration. Additionally, the timeout check fired before sleeping, without a final status poll. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Changes: - Move asyncio.sleep() before the timeout check so the trigger sleeps first, then evaluates the deadline. - Add a final is_still_running() call when the timeout fires so that jobs completing at the boundary are handled correctly. - Replace the misleading epoch-as-duration message with a clear "within the configured timeout" message. - Update existing timeout test and add a new test for the edge case where a job completes at the timeout boundary. Closes: apache#61979 Co-authored-by: Cursor <cursoragent@cursor.com>

boring-cyborg · 2026-02-16T07:07:27Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

SameerMesiah97

Looks good. I would fix the CI failures (one looks unrelated but the other prek related which you can fix).

Just a heads up: you might get conflicts if PR #61472 merges first as it is touching the same lines of code.

SameerMesiah97 · 2026-02-16T22:33:21Z

+ )
+ return
+ # Job reached a terminal state — exit loop to handle below.
+ break


It looks like the timeout emission could be extended by poll_interval, meaning the actual timeout could occur up to one full polling cycle later than the configured value. For example, with timeout=60s and poll_interval=30s, the timeout may not be emitted until around 90s depending on scheduling.
I believe this behavior was already present prior to this PR, so it’s not a regression. That said, we might consider sleeping for min(poll_interval, remaining_time) to align the timeout more closely with the configured value. This should not block the PR, but I think it might be worth exploring.

SameerMesiah97 · 2026-02-16T22:45:13Z

+ async def test_dbt_job_run_timeout_but_job_completes(
+ self, mock_get_job_status, mocked_is_still_running
+ ):
+ """Assert that a job completing at the timeout boundary is treated as success, not timeout."""


Nit: the docstring mentions "completing at the timeout boundary", but the test appears to simulate completion after the deadline has technically passed but before timeout emission. I would suggest clarifying it accordingly.

josh-fell · 2026-02-27T15:27:33Z

@eran-moses-human There are some merge conflicts now. Can you resolve and re-push when you get a chance?

josh-fell · 2026-03-11T17:15:17Z

@eran-moses-human Can you resolve conflicts here please when you get a chance?

potiuk · 2026-03-12T01:01:05Z

@eran-moses-human This PR has been converted to draft because it does not yet meet our Pull Request quality criteria.

Issues found:

❌ Merge conflicts: This PR has merge conflicts with the main branch. Your branch is 707 commits behind main. Please rebase your branch (git fetch origin && git rebase origin/main), resolve the conflicts, and push again. See contributing quick start.
❌ Unit tests: Failing: Basic tests / Breeze unit tests. Run failing tests with breeze run pytest <path> -xvs. See Unit tests docs.
❌ Pre-commit / static checks: Failing: CI image checks / Static checks. Run prek run --from-ref main locally to find and fix issues. See Pre-commit / static checks docs.

Note: Your branch is 707 commits behind main. Some check failures may be caused by changes in the base branch rather than by your PR. Please rebase your branch and push again to get up-to-date CI results.

What to do next:

The comment informs you what you need to do.
Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
Maintainers will then proceed with a normal review.

Converting a PR to draft is not a rejection — it is an invitation to bring the PR up to the project's standards so that maintainer review time is spent productively. If you have questions, feel free to ask on the Airflow Slack.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

josh-fell · 2026-03-12T01:28:17Z

@potiuk First of all, long-time, no talk; love the new automation as usual. One minor nit in the suggestion to resolve the merge conflicts:

Please rebase your branch (git fetch origin && git rebase origin/main),

Should be git fetch upstream && git rebase origin/main and/or link to the "How to rebase PR" docs, since folks are working with forks, I think?

potiuk · 2026-04-02T17:08:07Z

This pull request has been converted to draft due to quality issues more than a week ago and there has been no response from the author.

@eran-moses-human, you are welcome to reopen this PR when you are ready to continue working on it. Thank you for your contribution!

eran-moses-human · 2026-02-16T07:07:17Z

Summary

Fixes two bugs in DbtCloudRunJobTrigger.run():

Misleading error message: The timeout message printed self.end_time (an absolute epoch timestamp, e.g. 1771200015.8) labelled as "seconds", producing nonsensical output. Replaced with a clear "within the configured timeout" message.
Missing final status check: The timeout check fired without re-polling the job status. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Now performs one final is_still_running() call before yielding a timeout error.

Changes

providers/dbt/cloud/src/airflow/providers/dbt/cloud/triggers/dbt.py:
- Moved asyncio.sleep() before the timeout check
- Added a final is_still_running() call when the timeout fires
- Fixed the error message to no longer print epoch timestamp as duration
providers/dbt/cloud/tests/unit/dbt/cloud/triggers/test_dbt.py:
- Updated existing timeout test to match new error message
- Added new test test_dbt_job_run_timeout_but_job_completes for the edge case where a job completes at the timeout boundary

Closes#61979

Made with Cursor

…check The timeout error message in DbtCloudRunJobTrigger.run() printed self.end_time (an absolute epoch timestamp) labelled as "seconds", producing nonsensical output like "after 1771200015.8 seconds" instead of a meaningful duration. Additionally, the timeout check fired before sleeping, without a final status poll. A job completing during asyncio.sleep() could be incorrectly reported as timed out. Changes: - Move asyncio.sleep() before the timeout check so the trigger sleeps first, then evaluates the deadline. - Add a final is_still_running() call when the timeout fires so that jobs completing at the boundary are handled correctly. - Replace the misleading epoch-as-duration message with a clear "within the configured timeout" message. - Update existing timeout test and add a new test for the edge case where a job completes at the timeout boundary. Closes: apache#61979 Co-authored-by: Cursor <cursoragent@cursor.com>

boring-cyborg · 2026-02-16T07:07:27Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

SameerMesiah97

Looks good. I would fix the CI failures (one looks unrelated but the other prek related which you can fix).

Just a heads up: you might get conflicts if PR #61472 merges first as it is touching the same lines of code.

SameerMesiah97 · 2026-02-16T22:33:21Z

+ )
+ return
+ # Job reached a terminal state — exit loop to handle below.
+ break


It looks like the timeout emission could be extended by poll_interval, meaning the actual timeout could occur up to one full polling cycle later than the configured value. For example, with timeout=60s and poll_interval=30s, the timeout may not be emitted until around 90s depending on scheduling.
I believe this behavior was already present prior to this PR, so it’s not a regression. That said, we might consider sleeping for min(poll_interval, remaining_time) to align the timeout more closely with the configured value. This should not block the PR, but I think it might be worth exploring.

SameerMesiah97 · 2026-02-16T22:45:13Z

+ async def test_dbt_job_run_timeout_but_job_completes(
+ self, mock_get_job_status, mocked_is_still_running
+ ):
+ """Assert that a job completing at the timeout boundary is treated as success, not timeout."""


Nit: the docstring mentions "completing at the timeout boundary", but the test appears to simulate completion after the deadline has technically passed but before timeout emission. I would suggest clarifying it accordingly.

josh-fell · 2026-02-27T15:27:33Z

@eran-moses-human There are some merge conflicts now. Can you resolve and re-push when you get a chance?

josh-fell · 2026-03-11T17:15:17Z

@eran-moses-human Can you resolve conflicts here please when you get a chance?

potiuk · 2026-03-12T01:01:05Z

@eran-moses-human This PR has been converted to draft because it does not yet meet our Pull Request quality criteria.

Issues found:

❌ Merge conflicts: This PR has merge conflicts with the main branch. Your branch is 707 commits behind main. Please rebase your branch (git fetch origin && git rebase origin/main), resolve the conflicts, and push again. See contributing quick start.
❌ Unit tests: Failing: Basic tests / Breeze unit tests. Run failing tests with breeze run pytest <path> -xvs. See Unit tests docs.
❌ Pre-commit / static checks: Failing: CI image checks / Static checks. Run prek run --from-ref main locally to find and fix issues. See Pre-commit / static checks docs.

Note: Your branch is 707 commits behind main. Some check failures may be caused by changes in the base branch rather than by your PR. Please rebase your branch and push again to get up-to-date CI results.

What to do next:

The comment informs you what you need to do.
Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
Maintainers will then proceed with a normal review.

Converting a PR to draft is not a rejection — it is an invitation to bring the PR up to the project's standards so that maintainer review time is spent productively. If you have questions, feel free to ask on the Airflow Slack.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

josh-fell · 2026-03-12T01:28:17Z

@potiuk First of all, long-time, no talk; love the new automation as usual. One minor nit in the suggestion to resolve the merge conflicts:

Please rebase your branch (git fetch origin && git rebase origin/main),

Should be git fetch upstream && git rebase origin/main and/or link to the "How to rebase PR" docs, since folks are working with forks, I think?

potiuk · 2026-04-02T17:08:07Z

This pull request has been converted to draft due to quality issues more than a week ago and there has been no response from the author.

@eran-moses-human, you are welcome to reopen this PR when you are ready to continue working on it. Thank you for your contribution!