Ran into it - apparently nobody else is on 23.1 yet but I would consider this one rather problematic.
Error when trying to view Manage Locks in Studio or Unity Client:
This basically stops the Web Client from being able to log in. It also throws anytime you go to view locks in anything that isn't the Thick Client (Studio, Unity, etc.)
The next symptom is, if you go to check something out in Studio, it does so, but then when you go to the File menu:
Before
Immediately After The Error
Diagnostics
System.NullReferenceException: Object reference not set to an instance of an object. at Hyland.Data.DisposableResults.get_FieldCount() at Hyland.WorkView.Core.Workflow.WorkViewWorkItem..ctor(ISession session, IDisposableResults result, IEnumerable`1 displayitems, Boolean retrieveassignments, Dictionary`2 mapOfEncryptedAttributes, IProviderAccess providerAccess, IWorkflowProviderAccess workflowProviderAccess, ILegacyWorkView legacyWorkView, IWorkflowUtility workflowUtility, IAttributeEncryptionService attributeEncryptionService) at Hyland.WorkView.Core.Workflow.WorkViewWorkItemFactory.CreateWorkViewWorkItem(ISession session, IDisposableResults result) at Hyland.Core.Workview.Workflow.WorkviewWorkItemMeta.findWorkItemForInternalClass(ISession session, Int64 id, Int64 classID) at Hyland.Core.Workview.Workflow.WorkviewWorkItemMeta.FindWorkItem(ISession session, Int64 id, Int64 classID, Boolean applySecurity) at Hyland.Workflow.Core.WorkItemMeta.WorkItemMetaService.FindWorkItem(ISession session, WorkItemType workItemType, Int64 id, Int64 classID) at Hyland.Core.Configuration.Repository.ServerMethods.ServerMethodsImpl.GetLockDetail(LockedObject e, Session state) at Hyland_Core_LockedObjectElementSerializer412521349.CreateElement(Element , Object , Object ) at Hyland.Types.Serialization.ElementSerializer`1.CreateElementList(IEnumerable`1 list, Object state, Predicate`1 predicate) at Hyland.Core.Configuration.Repository.ServerMethods.ServerMethodsImpl.<GetServerLocksAsync>b__47_0() at Hyland.Core.Configuration.Repository.ServerMethods.ServerMethodsBase.<>c__DisplayClass3_0`1.<RunAsync>b__0() at Hyland.Common.Core.Utility.AsyncUtility.<>c__DisplayClass0_0`1.<RunAsync>b__0() at System.Threading.Tasks.Task`1.InnerInvoke() at System.Threading.Tasks.Task.Execute()
Didn't seem to affect the ability to check in/check out lifecycles or make changes and save them.
Problem is, for whyever the Web was built to do that lock checking before loading, the issue makes the Web completely unusable. Unity still works.
Doesn't matter whether Local vs. App Server connected. IISRESET does nothing.
Solution (strong theory, I can't say for 100%)
Since this was non-PROD I was able to go through, purge objects, do some validations on Workview applications and undo recent build. This didn't resolve Studio; but Unity finally was able to display the window, showing a Process Lock. Clearing that put everything back to normal, including Studio.
Through process of elimination here's my strong theory:
I was testing the new Handler Rule functionality with embedded filters. In this scenario, it's to change the constraint based on user group. This worked intermittently; but then started throwing errors and less consistently applying. The final error that I could get, talked about an extra (or missing) parentheses somewhere (the Rule interface is basically just building a script under the hood); but when the Web stopped allowing access, I couldn't get to Developer Tools to triage.
I'm of the opinion that one of the conditions created a sort of feedback loop without telling the interface.
The specific condition was, if a user is in Group A, there are two Constraint Sets that need to be applied (instead of creating a single linked 'OR' Constraint Set), such that it's treated as an AND in the Rule interface, as a test of what all it can do. I'm of the belief that this actually isn't supported, even though the Rule interface lets you do it - which I would consider a problem where I would expect it to disallow it. A junior developer would have no way of knowing what was wrong or why, and in shops that have more than one or two people concurrently building in the same environment, you potentially could inadvertently shut down your development lifecycle and lose hours of work (because Studio doesn't do autosave or at least preserve local build regardless of application server connection state, because some things cannot use Local Mode).
I was more concerned about the Web completely blowing up when this happened (effectively, a simple Process Lock) and that there's no other way (Thick Client doesn't show these types of Process Locks because Workview isn't supported in Thick Client).
