fix: stop scheduled instantiation notifications for deleted instances, and let Notifications retry when the instance lookup fails - #1873

The app registers a condition endpoint on the instantiation notification it orders, and Altinn Notifications asks it whether to send when the scheduled time comes. The callback answered "send" whenever it couldn't use the instance:

• A deleted instance is still returned by Storage until it is purged, with a process that never ended, so it was sent. Once purged, the lookup throws, and the catch-all answered "send".
• An app without Maskinporten can't read the instance as service owner, so every callback failed silently and answered "send", for deleted and submitted instances alike. This is what the reports in Planlagte instansieringsvarsler sendes etter sletting eller innsending #1864 ran into.
• A transient error also answered "send", so the condition was never checked for that attempt.

The callback now:

• answers "don't send" when the instance is soft- or hard-deleted, before the app's ICancelInstantiationNotification is asked;
• answers "don't send" when Storage returns 404;
• answers 500 on any other failure. Altinn Notifications retries a failed condition check once and sends the notification if the retry fails too, so a network blip delays the notification rather than losing it;
• logs a missing Maskinporten configuration as an error, since the condition can then never be checked.

The 404 rule relies on Storage answering 404 only for an instance that doesn't exist. Today Storage turns any error into 404; Altinn/altinn-storage#1130 changes that to 500, and this should not ship before it is deployed.

The ICancelInstantiationNotification docs now say that the default sends until the process has ended, which is not necessarily when the form is submitted.

Related

• Closes Planlagte instansieringsvarsler sendes etter sletting eller innsending #1864
• fix: return 500 instead of 404 when reading an instance fails altinn-storage#1130

🤖 Generated with Claude Code