Hi @bdocken,
Great that the product team will be looking at your workspace directly -- that is the fastest path to a definitive fix for the redirect loop and React error #185 you are seeing. While you wait for that investigation to complete, here are a few additional things that may help move things along or provide a workaround in the meantime.
UNDERSTANDING WHAT IS HAPPENING
The "Minified React error #185" with a navigation/redirect loop on the Tasks tab is a client-side rendering failure. When the Jobs UI loads the Tasks tab, it makes several API calls in the background to resolve details about every task's referenced resources (compute configuration, notebooks or scripts, cluster policies, pipelines, etc.). If any of those calls returns an unexpected response for a non-admin user, the UI can enter a redirect loop instead of rendering gracefully. Admins do not hit this because they implicitly have full access to all workspace objects.
The fact that granting Can Manage and even job ownership did not resolve it tells us the issue is likely not with the job-level ACL itself, but with a resource referenced by one or more tasks within the job.
WHAT TO CHECK WHILE WAITING FOR THE PRODUCT TEAM
1. Browser Console Network Tab
This is the single most useful diagnostic you can capture. Have a non-admin user:
- Open Chrome DevTools (F12) before navigating to the job
- Go to the Network tab and check "Preserve log"
- Navigate to the job and click the Tasks tab
- Look for any API requests returning 403 (Forbidden) or 500 status codes
- The URL path of the failing request will tell you exactly which resource is the problem (e.g., /api/2.0/clusters/get, /api/2.0/policies/clusters/get, /api/2.0/workspace/get-status)
If you can share which API endpoint is returning the error (no sensitive data needed, just the URL path and HTTP status), that would also help the product team pinpoint the issue faster.
2. Cluster and Cluster Policy Permissions
Even though you granted broad job-level permissions, cluster and cluster policy permissions are separate. For each task in the job, check what compute is assigned and verify the non-admin user has:
- CAN ATTACH TO on any all-purpose clusters referenced by tasks
- CAN USE on any cluster policies governing job clusters
You can check cluster policies under Compute > Policies in the workspace sidebar.
3. Notebook and Source Permissions
If any task references a notebook, Python file, or JAR, the user needs at least CAN READ on those resources (or the enclosing folder). This is separate from job permissions.
4. Pipeline Task Permissions
If any task is a Pipeline (Lakeflow Spark Declarative Pipelines (SDP)) task, the user needs at least CAN VIEW on the pipeline object itself. Check this under Lakeflow Pipelines in the sidebar.
POTENTIAL WORKAROUND
While the product team investigates, you may be able to work around this by having non-admin users view job run results through an alternative path:
- Instead of navigating through Jobs > [Job] > Tasks, try going to Jobs > [Job] > Runs, then clicking into a specific run. The Runs detail view sometimes renders successfully even when the Tasks tab does not, because it resolves resources differently.
- You can also use the Jobs API to retrieve task details programmatically:
GET /api/2.1/jobs/get?job_id=<JOB_ID>
This returns the full job definition including all tasks, which can be useful as a temporary workaround.
RELEVANT DOCUMENTATION
- Job access control (permission levels and what each grants):
https://docs.databricks.com/security/auth/access-control/
- Manage entitlements (verify users have Workspace access entitlement):
https://docs.databricks.com/security/auth/entitlements
- Configure job tasks:
https://docs.databricks.com/jobs/configure-task
- Jobs API reference (for programmatic access as workaround):
https://docs.databricks.com/api/workspace/jobs/get
SUMMARY
Since the product team is already engaged and will have direct access to your workspace, you are on the right track. The redirect loop pattern you described (with changing query parameters) is consistent with the UI failing to resolve a dependent resource permission and retrying, which eventually triggers the React error. The browser console Network tab capture will be the most valuable diagnostic to share with them.
Let us know how it goes -- happy to help further once the investigation turns up specifics.
* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.
