NOI modification card is deleted but request remains
- Dominant language
- TypeScript
- Stars
- 10
- Forks
- 0
- Avg merge
- 20h 8m
- Merged PRs (30d)
- 30
Description
**Describe the Bug**
NOI ID 102073 has three decisions and 3 modification requests. The user called me with a bug where the third modification card was never created. I looked into the database and it seems that the card associated with the third modification was created but deleted a short time later. User says they didn't delete the card. And user cannot delete the latest modification request even though the delete button is correctly enabled (get error toast).
It's also odd that the second modification card was also deleted, but the modification request remains.
https://alcs-metabase-prod.apps.silver.devops.gov.bc.ca/question/1169-bug-with-102073-sangha-deleted-modification-cards
**Expected Behaviour**
Hard to say where the error is, but generally I would expect that if the user deletes the modification request, the card is deleted with it. There shouldn't be a way for the user to delete a modification card without also deleting the request from the Post-Decision page. When the delete button is enabled on the Modification Request, user should be able to delete the request.
**Actual Behaviour**
Somehow the card has been deleted but the modification request remains. User can click delete button on Modification request, but gets error toast and delete is not successful.
** Steps To Reproduce**
I haven't been able to reproduce this behaviour... So I'm fine if the fix (after considering db integrity) is to clear the audit_deleted_date_at value on both deleted cards. If it happens again in the future, hopefully we can get more information to reproduce. See the metabase report for the three modification cards associated with the file, showing that two of the cards have deleted dates.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the Metabase report for NOI 102073 and inspect the three modification-card records alongside their requests, including audit_deleted_date_at. Trace the Post-Decision page delete action and its error toast. Done means the card and modification request remain consistent, and an enabled delete action succeeds.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100