Repository navigation
refactor(stovepipe): decouple issue tracking DLQ recovery - #1029
Merged
Merged
Conversation
Summary: Issue-tracking recovery constructs the normal controller with an empty topic registry just to reuse history persistence. Give the DLQ controller its own dependencies and extract shared issue-history persistence into a helper, so recovery has no normal controller or publishing dependency. Keep recovery behavior, constructor arguments, logger names, and metric scopes unchanged. Test Plan: The issue-tracking suite exercises cursor fencing, retained openings and closings, history repair, abandonment retries, and delayed deliveries. Ran that suite and the reference server suite, plus formatting, lint, module-tidy, and Gazelle checks. Revert Plan: Revert this PR.
mnoah1
added a commit
that referenced
this pull request
Nov 6, 2026
Summary: Publish an issue.opened hook after an opening's history and projections are durable, including reopenings. Retries retain the event ID and transition timestamp. Pass the queue already available during reconciliation, and keep hook publication in normal processing so DLQ recovery only repairs state and abandons failed work. Add generic namespaced issue metadata that survives observations, closure, and reopening through version-guarded snapshot updates. Append its nullable JSON column at the end of issue_state; provision that column before deploying code that uses it. Hook implementations can use the metadata to retain external references and delivery state. Builds on #1029, which separates DLQ recovery from the normal controller. Test Plan: TestIssueOpeningHookLifecycle covers openings and reopenings; TestIssueOpeningHookRetriesAfterDurableHistory covers stable retry identity and persistence ordering; TestIssueOpeningHookSkippedByDLQ verifies abandonment with a failing hook publisher. Storage unit and MySQL integration tests cover metadata round trips and version guards. Ran the hook-event, issue-tracking, entity, MySQL storage, and reference server suites, the issue-state MySQL integration cases, and formatting, lint, module-tidy, and Gazelle checks. Revert Plan: Revert this PR. The nullable metadata column can remain in place.
mnoah1
marked this pull request as ready for review
November 6, 2026 20:44
mnoah1
requested review from
a team,
behinddwalls and
sbalabanov
as code owners
November 6, 2026 20:44
prathshenoy
approved these changes
Nov 6, 2026
prathshenoy
pushed a commit
that referenced
this pull request
Nov 6, 2026
Summary: Publish an issue.opened hook after an opening's history and projections are durable, including reopenings. Retries retain the event ID and transition timestamp. Pass the queue already available during reconciliation, and keep hook publication in normal processing so DLQ recovery only repairs state and abandons failed work. Add generic namespaced issue metadata that survives observations, closure, and reopening through version-guarded snapshot updates. Append its nullable JSON column at the end of issue_state; provision that column before deploying code that uses it. Hook implementations can use the metadata to retain external references and delivery state. Builds on #1029, which separates DLQ recovery from the normal controller. Test Plan: TestIssueOpeningHookLifecycle covers openings and reopenings; TestIssueOpeningHookRetriesAfterDurableHistory covers stable retry identity and persistence ordering; TestIssueOpeningHookSkippedByDLQ verifies abandonment with a failing hook publisher. Storage unit and MySQL integration tests cover metadata round trips and version guards. Ran the hook-event, issue-tracking, entity, MySQL storage, and reference server suites, the issue-state MySQL integration cases, and formatting, lint, module-tidy, and Gazelle checks. Revert Plan: Revert this PR. The nullable metadata column can remain in place.
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
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.
Summary
Issue-tracking recovery constructs the normal controller with an empty topic registry just to reuse history persistence. Give the DLQ controller its own dependencies and extract shared issue-history persistence into a helper, so recovery has no normal controller or publishing dependency. Keep recovery behavior, constructor arguments, logger names, and metric scopes unchanged.
Test Plan
The issue-tracking suite exercises cursor fencing, retained openings and closings, history repair, abandonment retries, and delayed deliveries. Ran that suite and the reference server suite, plus formatting, lint, module-tidy, and Gazelle checks.
Revert Plan
Revert this PR.
Stack