The reason this happens is that after an update of one field, it is quite likely that other fields have changed due to many different reasons, some of which are Clarity business logic prevents updating of a field, calculated attributes change, display mappings change, any kind of data coupling across fields.
So the process we have today, is make a PATCH api call, then make a GET api call to refresh all of the fields. What is happening is that the GET call is significantly slower than the PATCH call. What we have observed in this rapid updating is that for every one field that updates successfully, the immediate next field does not update.
Here is an illustration of what is happening:
Field 1 - click to focus, paste text, blur (when clicking into Field 2)
GET all fields
Field 2 - click to focus, paste text, blur (when clicking into Field 3)
GET F1 updates all fields, with Field 2 previous value (empty)
PATCH F2 (field is blank, api call is never made)
Field 3 - click to focus, paste text, blur (when clicking into next field)
GET all fields (updates correctly)
This is currently working as design.
A user story will be raised by Engineering and revisit it in the future. The next time there is some refactoring work needed for the DETAILS page they will make this story an item to further investigate.