# HG changeset patch
# User Pierre-Yves David <pierre-yves.david@octobus.net>
# Date 1677014052 -3600
# Node ID e5f5f1c1c452e23107aa35cf34d0042aa9e0488c
# Parent  9e1debbb477ed184fcf4030dde124ab0248b580a
status: invalidate dirstate  on LockError

If we cannot take the lock, someone else is modifying the repository. Let us
discard dirstate uncommitted data before exiting the status code.

Having a clean dirstate after such operation seems safer.

Strictly speaking, there is a small behavior change in the following situation:

* process A call `status` outside of the `wlock`
* process B grab the `wlock`
* process A fails to acquires the lock to write status fixup
* process B release the `wlock` *without touching the dirstate*
* process A later grab the `wlock`
* process A can write dirstate update from earlier `status`

However this is a fairly hypothetical situation :
* process A has to be raced
* process B have to not update the dirstate
* process A has to run another *unrelated* operation later.

This seems rare enough to overlook.

I am stating that the two operations in process A has to be unrelated.
Otherwise,  collecting status data outside of the lock to use them inside the
lock is racy. Any other process could move things around (eg: the working copy)
making the data collected during status irrelevantor even harmful.

If such code exists, it should be fixed ASAP.

diff -r 9e1debbb477e -r e5f5f1c1c452 mercurial/context.py
--- a/mercurial/context.py	Tue Feb 21 16:20:11 2023 +0100
+++ b/mercurial/context.py	Tue Feb 21 22:14:12 2023 +0100
@@ -1889,7 +1889,7 @@
                         for ps in poststatus:
                             ps(self, status)
             except error.LockError:
-                pass
+                dirstate.invalidate()
             finally:
                 # Even if the wlock couldn't be grabbed, clear out the list.
                 self._repo.clearpostdsstatus()