Skip to content
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

[Bug] return in finally can swallow exceptions #10904

Open
2 tasks done
iritkatriel opened this issue Oct 22, 2024 · 3 comments
Open
2 tasks done

[Bug] return in finally can swallow exceptions #10904

iritkatriel opened this issue Oct 22, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@iritkatriel
Copy link

Is this a new bug in dbt-core?

  • I believe this is a new bug in dbt-core
  • I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

in

return status, message
there is a return statement in a finally block, which would swallow any in-flight exception.

This means that if an exception other than DbtRuntimeError is raised from the try body, or any exception is raised from the except: clause, it will not propagate on as expected.

See also https://docs.python.org/3/tutorial/errors.html#defining-clean-up-actions.

Expected Behavior

Refactor so that there is no return in finally.

Steps To Reproduce

NA

Relevant log output

No response

Environment

- OS: Any
- Python: source code, main

Which database adapter are you using with dbt?

other (mention it in "Additional Context")

Additional Context

No response

@iritkatriel iritkatriel added bug Something isn't working triage labels Oct 22, 2024
@dbeatty10
Copy link
Contributor

Thanks for reporting this @iritkatriel !

I'm curious how you discovered this. Did you actually notice something behaving incorrectly? Or is this some code you noticed that could theoretically have unintended behavior?

It looks to me like this code was added in #10699 which is not in dbt-core v1.8 but it slated for release in dbt-core v1.9.

@iritkatriel
Copy link
Author

I'm curious how you discovered this.

I'm doing some analysis on return/break/continue in finally blocks (how often its use is correct/incorrect in real code). So running static analysis on lots of open source code. While I'm at it, I'm filing issues when I think it's worth looking into.

@dbeatty10
Copy link
Contributor

Thanks again for raising this @iritkatriel 🤩

After discussing briefly with @peterallenwebb, he affirmed that we'd be interested in refactoring this section of code (specifically the part you mentioned):

def get_execution_status(sql: str, adapter: BaseAdapter) -> Tuple[RunStatus, str]:
if not sql.strip():
return RunStatus.Success, "OK"
try:
response, _ = adapter.execute(sql, auto_begin=False, fetch=False)
status = RunStatus.Success
message = response._message
except DbtRuntimeError as exc:
status = RunStatus.Error
message = exc.msg
finally:
return status, message

@dbeatty10 dbeatty10 removed the triage label Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants