Record Type Precedent Check Erroring

Question

We recently did a bit of an object purge on our DEV site to clean out some unused or obsolete objects. We checked for dependencies before deleting anything, but apparently we didn't check hard enough. I have a process model that contains 2 Start Process nodes, that is now displaying an error on the Setup tab (see image below). This happens even when adding a new Start Process node to the process model, but other process models work fine. The uuid listed in the error is one of the record types we deleted. 
 
 I have process variables that are type Record Type, so I started by checking the precedents of that record type. I found one that, when trying to expand its precedents tree gives me the error message: 
 
 Going in to that record type directly and attempting to view it's precedents just gives me a " Record field's uuid must not be null" error, and no precedents are displayed. However the record behaves completely normally apart from this and other apps that use it seem to be working properly. I've looked in the tomcat-stdout log, but it doesn't provide any additional information it just restates the error that is displayed. I also tried adding this record type to a package by itself, then checking for missing precedents that way. This didn't give me an error, but I also didn't find any issues in any of the precedents that could be causing this. 
 Does anyone have any thoughts on how I could resolve this? Any help is greatly appreciated!

Stefan Helzle · Answer

If you cannot import that missing record type(s) from a different environment, you will probably have to rebuilt the model. Or at least delete things until it work, follow the dependencies.

Shubham Aware · Answer

Record type still references the deleted object internally. I would recommend open the record type re-save it to refresh references. Check and update any relationships, custom fields, or expressions that might reference the deleted UUID. For the process model, remove and re-add the process variables that use this record type. If these steps don't work, you'll need to recreate the record type entirely and update all references to use the new one instead.

Shubham Aware · Answer

Since R3 has internal corruption that persists even in new process models and after restoring R1/R2, you'll likely need to recreate it. The server reboot is worth trying first, but given all your troubleshooting, R3's metadata appears permanently corrupted. Export R3 for reference, then create a new record type and test it before updating all dependent objects to use the new record type.