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

[CT-1032] grant_access_to only works reliably in single threaded mode #266

Closed
judahrand opened this issue Aug 11, 2022 · 4 comments · Fixed by #404
Closed

[CT-1032] grant_access_to only works reliably in single threaded mode #266

judahrand opened this issue Aug 11, 2022 · 4 comments · Fixed by #404
Labels
bug Something isn't working help_wanted Extra attention is needed Stale

Comments

@judahrand
Copy link

Describe the bug

A clear and concise description of what the bug is. What command did you run? What happened?

Steps To Reproduce

In as much detail as possible, please provide steps to reproduce the issue. Sample data that triggers the issue, example model code, etc is all very helpful here.

Expected behavior

A clear and concise description of what you expected to happen.

Screenshots and log output

If applicable, add screenshots or log output to help explain your problem.

System information

The output of dbt --version:

<output goes here>

The operating system you're using:

The output of python --version:

Additional context

Add any other context about the problem here.

@judahrand judahrand added bug Something isn't working triage labels Aug 11, 2022
@github-actions github-actions bot changed the title grant_access_to only works reliably in single threaded mode [CT-1032] grant_access_to only works reliably in single threaded mode Aug 11, 2022
@jtcohen6 jtcohen6 added duplicate and removed triage labels Aug 11, 2022
@jtcohen6
Copy link
Contributor

Hey @judahrand, this is a documented limitation of grant_access_to in dbt-bigquery: https://docs.getdbt.com/reference/resource-configs/bigquery-configs#limitations

The main proposal for fixing this bug is to "batch up" all dataset access grants to the end of an invocation, similar to the discussion in #87 (comment). I think that could be a reasonable approach—more efficient and single-threaded—at the cost of significant potential delay between when each view is (re)created, and when their access is authorized (all at once, after every model has run).

I'm going to close both of these issues in favor of a new one, just opened: #267

@jtcohen6 jtcohen6 closed this as not planned Won't fix, can't repro, duplicate, stale Aug 11, 2022
@judahrand
Copy link
Author

@jtcohen6 Is there something inherently wrong with just locking around the changes (other than slowing it down) as in #265? Even if only a temporary fix it's surely better for it to work and be slow than just not work at all?

@jtcohen6
Copy link
Contributor

@judahrand Fair! I called that out as an alternative in #267. I can reopen this bug as more narrowly scoped to just ensuring thread-safety.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 8, 2023

This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please remove the stale label or comment on the issue, or it will be closed in 7 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help_wanted Extra attention is needed Stale
Projects
None yet
2 participants