fix(alerts): register alert-notification kinds presets so ANS alerts fire - #1503
Merged
Conversation
…olves
cds.connect.to('alerts') throws 'No configuration found for
cds.requires.alert-notification' because the @sap-tutorials/cds-alert-notification
plugin sets requires.alerts.kind but never registers the matching
cds.requires.kinds presets. CAP resolves the kind BEFORE the plugin's
on('connect') handler runs, so the service was unreachable in every
profile — no deploy-lifecycle alert has ever been delivered (raise() is
fail-open and swallowed the error; the admin test-alert surfaces it).
Add the kinds block to cds.requires so the consumer resolves now, ahead
of the upstream plugin fix (cds-alert-notification#2, v1.0.1).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why no alerts have ever arrived
We wired BTP Alert Notification (deploy start/finish/fail + admin test-alert), the managed
alert-notificationinstance is bound to the live PROD srv,ChatSettings.alertsEnabledis on, and severity routing is correct — yet not one alert has been delivered.Root cause is a plugin bug:
@sap-tutorials/cds-alert-notification'scds-plugin.jssetscds.requires.alerts.kindbut never registers the matchingcds.requires.kindspresets. CAP resolves arequires.<svc>.kindagainstcds.requires.kindsbefore anyon('connect')handler runs, socds.connect.to('alerts')throws:Reproduced deterministically in all three profiles (prod
alert-notification, dev-console, test-memory).alerting.raise(), whosecatchis deliberately fail-open — it swallowed this connect failure every time. Hence the silence.raiseTest(), which surfaces the failure — that's the PROD error we saw.Fix
Add a
cds.requires.kindsblock registering the three sink kinds against the plugin impl. This unblocks PROD on the next srv deploy without waiting on the upstream plugin release.Verified with the real
@sap/cds+ plugin loaded: productionkind=alert-notificationnow resolves (preset FOUND); all four profiles (prod/dev/test/hybrid) resolve.Upstream
The proper home for this is the plugin itself — companion PR: sap-tutorials/cds-alert-notification#2 (v1.0.1) registers the presets + a regression test. This consumer-side block is the belt to that suspenders and can stay as a defensive override even after the plugin bumps.
Deploy note
Requires a full srv deploy (
npm run deploy -- --env prod) to take effect — config-only change, no schema/build impact.