Summary
Archiving a check keeps its Firestore document — and therefore its name — forever, but nothing in the API or the UI can bring an archived check back. The 409 that #484 introduces tells the user to "restore" the conflicting check, an action the product cannot perform, so a name that has been used and removed is permanently unusable.
Details
Archiving is a flag, not a delete (EligibilityCheckResource.java:404):
check.setIsArchived(true);
and the working check's document id is derived from owner + module + name (EligibilityCheckRepositoryImpl.java:192), so the archived document keeps holding that id. Meanwhile getWorkingCustomChecks filters archived checks out of the list (EligibilityCheckRepositoryImpl.java:34), so the check occupying the name is invisible.
There is no way back:
- the only archive-related endpoint is
POST /{checkId}/archive (EligibilityCheckResource.java:380); there is no unarchive counterpart
EditCheckRequest carries only description and parameterDefinitions, so PUT cannot clear the flag
- the frontend has no restore action and no view that lists archived checks
The duplicate-name 409 added for #484 nevertheless says (EligibilityCheckResource.java:137):
A check named "X" in module "Y" is archived. Restore it or choose a different name.
Reproduction
- Create a check named
incomeCheck in module income.
- Remove it from the check list (this archives it).
- Create
incomeCheck in income again.
Expected: the name is free again, or there is some way to get the old check back.
Actual: 409 instructing the user to restore a check they cannot see and cannot restore. That name and module pair can never be used again.
This is the ordinary remove-and-recreate flow, not an edge case.
Possible directions
- add an unarchive path (endpoint plus a way to see archived checks) so the message becomes true
- or reuse/overwrite the archived document when a create collides with it
- or, at minimum, change the message to state what actually happened — the name is held by a removed check and cannot currently be reused
Follow-up to #484.
Summary
Archiving a check keeps its Firestore document — and therefore its name — forever, but nothing in the API or the UI can bring an archived check back. The 409 that #484 introduces tells the user to "restore" the conflicting check, an action the product cannot perform, so a name that has been used and removed is permanently unusable.
Details
Archiving is a flag, not a delete (
EligibilityCheckResource.java:404):and the working check's document id is derived from owner + module + name (
EligibilityCheckRepositoryImpl.java:192), so the archived document keeps holding that id. MeanwhilegetWorkingCustomChecksfilters archived checks out of the list (EligibilityCheckRepositoryImpl.java:34), so the check occupying the name is invisible.There is no way back:
POST /{checkId}/archive(EligibilityCheckResource.java:380); there is no unarchive counterpartEditCheckRequestcarries onlydescriptionandparameterDefinitions, soPUTcannot clear the flagThe duplicate-name 409 added for #484 nevertheless says (
EligibilityCheckResource.java:137):Reproduction
incomeCheckin moduleincome.incomeCheckinincomeagain.Expected: the name is free again, or there is some way to get the old check back.
Actual: 409 instructing the user to restore a check they cannot see and cannot restore. That name and module pair can never be used again.
This is the ordinary remove-and-recreate flow, not an edge case.
Possible directions
Follow-up to #484.