-
Notifications
You must be signed in to change notification settings - Fork 10
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] "Workspace capacity assignment in progress" while refreshing existing Fabric workspace resource #232
Comments
Hi @fstraetz Is there a chance that your solution sends more than 50 API requests in 1 minute? (we can assume that each object for a resource or data-source is on average ~2x requests) The Provider works on top of public Fabric API (https://learn.microsoft.com/en-us/rest/api/fabric/) which has a limit of 50 req/min per principal before the throttling starts (https://learn.microsoft.com/en-us/rest/api/fabric/articles/throttling) The provider handles throttling and waits based on "Retry-After" value, but it can significantly extend the total execution time and exceed the default timeout value. |
Thanks for you response @DariuszPorowski If your estimate of 2 requests per (data) resource is correct, our solution should have quite a bit of leeway. I just checked and concerning the Fabric provider we currently have:
So, about 32 requests. (My assumption here is that resources of type "fabric_workspace_role_assignment" with principal type "Group" still count as a single resource when it comes to the number of requests, no matter the number of security principals in the given group.) Taking a look at the log, it seems that the "Workspace capacity assignment in progress" issue blocks for about 10 minutes (more likely longer, as the timeout definitely ends the OpenTofu process / log, but maybe not the issue). So my expectation would be that, even if the throttling of the Fabric API was the culprit, the retrying (which seems to happen regularly, according to the log?) should be successful at some point during these 10 minutes. Unless the Retry-After header can be > 10 Minutes and the retrying which can be seen in the the log is showing something different, independent from the Retry-After mechanism. Also, considering the message "Workspace capacity assignment in progress", I would not think of this being a throttling issue (though I also have no clue about how all of this is implemented behind the scenes). And it sometimes blocks for hours (like the day before yesterday) and sometimes it works absolutely fine (like yesterday and today when I did some smaller changes). I would expect the throttling to behave in a deterministic manner. |
Hi @fstraetz Your assumptions are valid as long as only one API operation is executed at a time. By default, Terraform prepares the execution graph with 10 concurrent operations. You may consider increasing provider timeouts and additionally preventing too many concurrent operations by Terraform. For more information, please refer to: https://registry.terraform.io/providers/microsoft/fabric/latest/docs/guides/troubleshooting#operations-take-too-long-to-complete-or-timeout Please note, we do not officially support OpenTofu. All diagnostics and troubleshooting are performed exclusively with Terraform binaries. |
🐛 What happened?
Sometimes (as in, the problem seems to occur nondeterministic), the Terraform Fabric provider seems to have a problem refreshing the state of existing Fabric workspaces. Terraform / OpenTofu will then log the message "Workspace capacity assignment in progress" until it a timeout occurs. After this happens, the "diagnostic detail" will be "context deadline exceeded".
This seems to happen randomly, even if no changes whatsoever (so neither Terraform / OpenTofu nor GUI) have been made to the workspaces in question.
I am pretty sure this has nothing to do with network problems (on our side), as all other Azure specific requests seem to work fine. Usually, OpenTofu even displays a correct execution plan. It also should have nothing to do with "advanced stuff" like using
resource "fabric_workspace_role_assignment"
orresource "fabric_workspace_git"
, as the problem occurs and disappears no matter whether these resources are linked to the respective workspaces or not.This bug is basically the same as #76, which got closed after the problem (also randomly) disappeared for the user in question.
Especially the nondeterministic nature of this problem makes the Fabric provider (I know, I know, it is in beta state) almost unusable.
🔬 How to reproduce?
data "fabric_capacity"
.resource "fabric_workspace"
.resource "fabric_workspace_role_assignment"
resources.resource "fabric_workspace_git"
resource.terraform plan
/tofu plan
multiple times at random times until it fails.terraform plan
/tofu plan
and it might work again.🏗️ Code Sample / Log
📷 Screenshots
No response
📈 Expected behavior
The
terraform plan
/tofu plan
call should run without hangups or errors (assuming all the definitions are correct, of course).🌌 Environment (Provider Version)
0.1.0-beta.8
🌌 Environment (Terraform Version)
OpenTofu v1.8.8
🌌 Environment (OS)
Linux
📎 Additional context
No response
🔰 Code of Conduct
The text was updated successfully, but these errors were encountered: