chore: Replace update with simple delete for removeDeliveryOption

[dsamojlenko]

Summary | Résumé

removeDeliveryOption was attempting to use a prisma.update to remove the deliveryOption record when changing to API mode. This was not working as expected, and was throwing an incorrect TemplateAlreadyPublishedError.

Modified to:

• Initial isPublished check and throw exception as published templates cannot be changed
• Delete any DeliveryOptions for template

[github-actions]

🧪 Review environment

https://itcmttfywsep45oqstddwchqja0ujbmq.lambda-url.ca-central-1.on.aws/

[bryan-robitaille]

Just confirming that we're allowing the removeDeliveryOption to run on published forms?
The initial reason to use the prisma.template.update() was the ability to check if the form was published in the unique where:{ } before deleting the delivery option.

[dsamojlenko]

I'll take this back to draft, as there seems to be another bug introduced.

But yeah maybe this will just have to be two queries either way:

Check to make sure it's not published, then delete.
OR
Check to see if there is a DeliveryOption and use the update syntax.

The update syntax fails if there was no DeliveryOption set.

[bryan-robitaille]

We can also catch that specific error in the prisma chain and ignore it.

[dsamojlenko]

Seems to throw the same error in both cases.

Template with a DeliveryOption and published = true : P2025

And

Template with no DeliveryOption and published = false : P2025

...doesn't make a whole lot of sense as it says "No 'DeliveryOption' record was found ..." in both cases.

[dsamojlenko]

Pushed a commit with the split check, then delete.
I couldn't get it to work with just the update call.

[bryan-robitaille]

If we want it to fail silently do we even need to return a descriptive error if the template is already published?

[bryan-robitaille]

In other words shouldn't the client side be verifying if the template is already published before trying to make the action call? And if someone tries to hit the action endpoint directly it just returns a generic error.

[timarney]

For the "live api key version" --- there is code that does the published check.

... depends on where we calling the code from.

Part of this was looking to ensure the server is cleaned up when saving to "the vault".

[timarney]

that said looks like Dave already made some further edits and checks

[bryan-robitaille]

I'm good with this solution for now. Ideally when we go back to refactoring the templates lib we can see if we can reduce the number of calls to the db.
For example, one of the reasons we have to check externally of the update function is to return a specific error. Quickly scanning the code-base I see that the TemplateAlreadyPublishedError and TemplateNotFound errors are generated in a few places but are never consumed or checked against. So the question becomes do we need to actually throw these custom errors?