Uploaded image for project: 'OpenLMIS General'
  1. OLMIS-4728

Requisition's properties can be overwritten if it's saved concurrently

    Details

    • Type: Bug
    • Status: Done
    • Priority: Critical
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 3.3.1
    • Component/s: Requisition
    • Labels:
    • Sprint:
      Parrot Sprint 100, Parrot Sprint 101, Parrot Sprint 102, Parrot Sprint 103
    • Story Points:
      8

      Description

      Submitting, authorizing or approving a requisition in multiple tabs (or after refreshing the page) can break its state. A status change is created, but the actual status and other properties are overwritten by the second save.

      Reproduction steps:

      1. Go to perftest.openlmis.org and log in as administrator
      2. Initiate a requisition for Comfort Health Clinic / Essential Meds
      3. Skip all except the first item, fill in all the required fields and click on the "Sync with Server" button. Wait for it to synchronize.
      4. Open this requisition in another, incognito tab
      5. In the original tab, submit the requisition
      6. After about 5 seconds, submit the requisition in the incognito tab
      7. The requisition fails to submit in the second tab and succeeds in the first one, but its status is still "Initiated"
      8. When trying to submit it again, an error message appears: "Failed to submit due to a duplicate status change"

      What happens on the backend:
      Assumptions: Save takes a considerable amount of time (say >15 seconds)

      1. The first synchronize / submit is called and shortly after a concurrent update is invoked
      2. Since the first update did not finish yet, the second update passes the validation we have (based on last updated date timestamp)
      3. The first update finishes and submit is invoked
      4. The requisition is successfully submitted and status change table is updated with new status change
      5. The second update finishes and overwrites what happened in previous save (most importantly status, but all other properties can be overwritten too)

      Please reach the tech committee with the proposed solution first, either on the call or via dev group.

        Attachments

        1. 1.png
          157 kB
        2. 2.png
          242 kB
        3. 3.png
          294 kB
        4. second tab - duplicate status change.png
          211 kB
        5. status changes not chronological.png
          200 kB

          Issue links

            Activity

              People

              • Assignee:
                sbrudzinski Sebastian Brudziński
                Reporter:
                jkondrat Jakub Kondrat
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 2 weeks, 6 hours Original Estimate - 2 weeks, 6 hours
                  2w 6h
                  Remaining:
                  Time Spent - 2 weeks, 4 days, 1 hour, 30 minutes Remaining Estimate - 1 hour
                  1h
                  Logged:
                  Time Spent - 2 weeks, 4 days, 1 hour, 30 minutes Remaining Estimate - 1 hour
                  2w 4d 1h 30m