Impressive bug summary (continuously updated)

Request asynchronous problem （20220627）

The appearance of the problem

Every time you switch tasks for patrol , Yes 5% About the probability of collapse

The root cause

When correct, the network request sequence ：

1. The front end requests /api/affair/inspection/mGetInspectionTask
2. The front end requests /api/affair/inspection/updateInspectionTask
3. /api/affair/inspection/updateInspectionTask modify the database status=2
4. /api/affair/inspection/mGetInspectionTask Arrive at the database and get status=2
5. /api/affair/inspection/updateInspectionTask Return front end results , Select this task to patrol
6. /api/affair/inspection/mGetInspectionTask return status=2 The results are given to the front end , The status is correct

Crash request sequence ：

1. The front end requests /api/affair/inspection/mGetInspectionTask
2. The front end requests /api/affair/inspection/updateInspectionTask
3. /api/affair/inspection/mGetInspectionTask Arrive at the database and get status=1
4. /api/affair/inspection/updateInspectionTask modify the database status=2
5. /api/affair/inspection/updateInspectionTask Return front end results , Select this task to patrol
6. /api/affair/inspection/mGetInspectionTask return status=1 The results are given to the front end , As a result, patrol inspection is not allowed

Solution

mGetInspectionTask During patrol task , If the timestamp of accessing the database is less than that of modifying the database , Then abandon this state