Introduce invariant in Locker::unlock that lock must have been previously acquired

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Catalog and Routing
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      If we can't find the requested resource, LockerImpl:unlock() returns false. However, there is a comment saying it is an invariant violation we try to release a lock not previously required. 

       

      Since the comment dates back to almost a decade ago, and is slightly misleading, we should probably remove it or reconsider if it is possible to guarantee we only unlock resources which have already been locked.

      We should try to re-introduce the invariant that Locker::unlock must be called on a resource previously locked by the Locker instance.

              Assignee:
              Unassigned
              Reporter:
              Haley Connelly
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: