implement _safe_* calls for applier_task in redash, scim, generic#507
implement _safe_* calls for applier_task in redash, scim, generic#507tnguyen-db wants to merge 15 commits intodatabrickslabs:mainfrom
Conversation
5c88480 to
c2acce5
Compare
Codecov Report
@@ Coverage Diff @@
## main #507 +/- ##
==========================================
+ Coverage 80.30% 80.81% +0.51%
==========================================
Files 31 31
Lines 3219 3284 +65
Branches 617 621 +4
==========================================
+ Hits 2585 2654 +69
+ Misses 489 488 -1
+ Partials 145 142 -3
|
larsgeorge-db
left a comment
There was a problem hiding this comment.
Please explain the change to me. I do not understand how the loop and the "retries on errors" achieve the same. More inline...
| raise RetryableError() from e | ||
|
|
||
| @retried(on=[RetryableError]) | ||
| def _safe_update_permissions( |
There was a problem hiding this comment.
This handles errors now, but how does this ensure all permissions have been applied successfully?
There was a problem hiding this comment.
If no error is returned, can we assume the permissions have been applied?
There was a problem hiding this comment.
Apparently not? Please consult with @renardeinside, as there are seemingly cases where the function returns without error, but the permission is not available? I am just making the point that before it looped over presence of permissions, not that it runs without exceptions.
There was a problem hiding this comment.
Yes, indeed, there is now _inflight_check to check if the permissions have been applied as expected in _applier_task for each type
There was a problem hiding this comment.
In general, when the API returns 200 and no error the permission should be applied. If it's not then it should be reported as a platform bug. What are the scenarios we try to cover here?
There was a problem hiding this comment.
Apparently, the API can be inconsistent, I don't know if the problem has been raised already to the platform
There was a problem hiding this comment.
Got it, we should fix that but this should also be reported to the platform.
|
Also, this adds a bunch of new code paths that the test now covers less. Please add more coverage in the tests. |
nfx
left a comment
There was a problem hiding this comment.
This PR introduces regressions, please address all the comments
| else: | ||
| raise RetryableError() from e | ||
|
|
||
| @retried(on=[RetryableError]) |
There was a problem hiding this comment.
No timeout configured. See how it's configurable for unit testing in other places
There was a problem hiding this comment.
Which timeout value do you suggest?
I haven't found examples on how to configure it in the unit tests.
I was rather thinking of mocking @retried in the unit tests, wdyt?
There was a problem hiding this comment.
@tnguyen-db did you look at this one?
ucx/src/databricks/labs/ucx/workspace_access/secrets.py
Lines 92 to 97 in bc7f29e
|
@larsgeorge-db I've then generalized the solution for |
| set_retry_on_value_error = retried(on=[RetryableError], timeout=self._verify_timeout) | ||
| set_retried_check = set_retry_on_value_error(self._safe_set_permissions) | ||
| set_retried_check(object_type, object_id, acl) | ||
|
|
||
| retry_on_value_error = retried(on=[ValueError], timeout=self._verify_timeout) | ||
| retried_check = retry_on_value_error(self._inflight_check) | ||
| return retried_check(object_id, object_id, acl) |
There was a problem hiding this comment.
@nfx is it the kind of logic you expect?
| sup = RedashPermissionsSupport(ws=ws, listings=[], verify_timeout=timedelta(seconds=1)) | ||
| with pytest.raises(TimeoutError) as e: | ||
| result = sup._applier_task( | ||
| sql.ObjectTypePlural.QUERIES, | ||
| "test", | ||
| [sql.AccessControl(group_name="group_1", permission_level=sql.PermissionLevel.CAN_RUN)], | ||
| ) | ||
| assert "Timed out after" in str(e.value) | ||
|
|
There was a problem hiding this comment.
@nfx same question as above but for the test
af4e3f1 to
80824c0
Compare
80824c0 to
7a5711e
Compare
06d311d to
4924012
Compare
4924012 to
79f7134
Compare
|
Closing this as merged |
Uh oh!
There was an error while loading. Please reload this page.