fix(yes-core): restore the failed-subscription Sentry notifier (B2BY-5189) - #36
Merged
Merged
Conversation
…5189)
yes-core's Railtie is a port of yousty-eventsourcing's — same
before_configuration, same middlewares — but the failed_subscription_notifier
block was dropped in the port. That hook is pg_eventstore's only death signal:
it fires once when a subscription exhausts its restarts and stays permanently
dead; per-failure errors are only recorded on the subscription row and never
reach Sentry, so without the hook the death is completely silent.
Consequence in production: during the W6 past-applications migration, AMS
process managers were killed and stayed dead overnight with no alert, while
company-manager's identical death alerted — CM had re-added the block by hand
in its own initializer, AMS had not. Every yousty-eventsourcing consumer was
covered by that gem's Railtie all along; the gap existed exactly for yes-core
consumers, and only CM's local patch hid it.
Extracted as Yes::Core::FailedSubscriptionNotifier rather than an inline proc:
Sentry is not a dependency of this gem (the Railtie registers the notifier only
when the host app loaded Sentry), so an inline block could not be specced —
the class can, with the constant stubbed. Two details preserved from the
original: hint: { ignore_exclusions: true }, so a death report can never be
swallowed by excluded_exceptions, and the failed_subscription_notifier tag that
Sentry alert routing keys on.
Once released and adopted, company-manager's and AMS's local initializer blocks
become redundant (they set the same notifier; last write wins, both identical).
Specs not run locally — the Gemfile pins ruby 3.4.5, not installed here; CI
runs the suite.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y1QwAKdjduR28wJdkc6idM
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y1QwAKdjduR28wJdkc6idM
ncri
approved these changes
Aug 20, 2026
Contributor
Author
|
We will release this change after the upgrade of the ES v3 |
aroeczek
added a commit
that referenced
this pull request
Aug 22, 2026
PR #36 added the failed-subscription notifier without a CHANGELOG entry, and it is now part of this release. Worth pairing explicitly: the UUID fix addresses a bug that KILLS subscriptions, and the notifier is what tells you when one has died -- yes-core services had neither until now.
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
2 participants
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.
Refs B2BY-5189. Companion to application_management_system#167 — this is the gem-level fix so every yes-core consumer is covered, the way
yousty-eventsourcingconsumers always were.The regression
yes-core's Railtie is a port of
yousty-eventsourcing's — samebefore_configuration, same middlewares — but thefailed_subscription_notifierblock was dropped in the port. That hook is pg_eventstore's only death signal: it fires once when a subscription exhausts its restarts and stays permanently dead. Per-failure errors are only recorded on the subscription row, never raised into Sentry — so without the hook, death is completely silent.Production consequence: during the W6 migration, AMS process managers died overnight with no alert, while company-manager's identical death alerted — CM had re-added the block by hand in its own initializer; AMS had not. Status across the platform:
yousty-eventsourcingyes-core)yes-core)Shape
Extracted as
Yes::Core::FailedSubscriptionNotifierrather than an inline proc: Sentry is not a dependency of this gem (the Railtie registers the notifier onlyif defined?(Sentry)), so an inline block couldn't be specced — the class can, with the constant stubbed.Preserved from the original:
hint: { ignore_exclusions: true }(a death report must never be swallowed byexcluded_exceptions) and thefailed_subscription_notifiertag Sentry alert routing keys on.After merge
Consumers pick it up on their next lockfile bump (git gem — merging to main is the release). CM's and AMS's local initializer blocks then become redundant — identical notifier, last write wins — and can be dropped in a cleanup.
Verification
Specs not run locally — the Gemfile pins ruby 3.4.5, which isn't installed on my machine; relying on CI for the suite.
ruby -cclean on all three files; the new spec mirrors the repo's conventions (stubbedSentryconstant,have_received,aggregate_failures).🤖 Generated with Claude Code
https://claude.ai/code/session_01Y1QwAKdjduR28wJdkc6idM