Remove legacy* executor hooks from main.ts; inline impl into YAML ops #1095
Labels
No labels
area:agents
area:dashboard
area:database
area:design
area:design-review
area:flows
area:infra
area:meta
area:security
area:sessions
area:webhook
area:workdir
security
type:bug
type:chore
type:meta
type:user-story
No milestone
No project
No assignees
2 participants
code-lead
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
charles/claude-hooks#1095
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As an operator, I want the three
legacy*wrapper hooks inmain.ts:3770-3791removed, so that the YAML executor stops needing imperative callbacks and PR-edit / issue-close / rebase-cascade side effects live entirely inside ops.Context
apps/server/src/main.ts:115-117aliases three handlers aslegacy*:legacyHandleIssueClosed(wired toprFlow.propagateIssueClosedhook)legacyHandlePrDependencyMarkers(wired toprFlow.applyDependencyMarkershook)legacyHandleStackedRebaseCascade(wired toprFlow.propagateRebaseCascadehook)These are imperative callbacks the YAML executor calls during flow dispatch — workaround until each was fully ported. With CI events + PR-closed cleanup landed (issues #1092 + #1093), we can flatten this indirection.
Acceptance criteria
Cascade hook → already covered
propagate_dependenciesop (kind: rebase-cascade) andflows/defaults/pr-merged.ymlfully replicatelegacyHandleStackedRebaseCascadebehaviour (parent SHA change → walk dependent PRs → dispatch rebase)prFlow.propagateRebaseCascadecallback wiring frommain.ts:3781handleStackedRebaseCascadefromevent-handlers.tsIssue-close hook
legacyHandleIssueCloseddoes beyondissue-closed.yml(likely the dependency-propagation side-effect: when an issue closes, find dependent issues whose blockers cleared and re-dispatch). Ifpropagate_dependenciesop already covers this, remove the callback wiring; else extend the op (kind: issue-closed) and then removeprFlow.propagateIssueClosedcallback wiring frommain.ts:3788handleIssueClosedfromevent-handlers.tsPR-edited / dependency markers hook
flows/defaults/pr-edited.ymlonpull_request: [edited]: calls existingpr_dependency_markersopprFlow.applyDependencyMarkerscallback wiring frommain.ts:3777handlePrDependencyMarkersfromevent-handlers.tsExecutor cleanup
prFlowcallback surface entirely from the YAML executor if no callbacks remain (separate concern — call it out in PR description if removed)setEventHandlersTriggerBus(setTriggerBus) — still needed for internal trigger publication (used bypublish_pr_mergedop from issue #1093)Tests
Out of scope
event-handlers.ts— separate ticket (Phase 6)Dependencies
event-handlers.tsedits; merging them first prevents merge conflicts on the same fileReferences
apps/server/src/main.ts:115-117(imports),main.ts:3770-3791(executor wiring)apps/server/src/domain/flows-yaml/ops/propagate_dependencies.ts(cascade op — already supportskind: rebase-cascade)apps/server/src/domain/flows-yaml/ops/pr_dependency_markers.tsflows/defaults/pr-merged.yml,flows/defaults/issue-closed.yml🤖 Auto-assigned to code-lead (heuristic: default → code-lead (no specific label match; safer than code)). Reply
/unassignto reroute.Merging into #1096
Verified during overnight Phase 4 implementation: the three YAML flows that drive this work already exist on
main:pr-merged.yml→propagate_dependencies(kind: rebase-cascade)(covershandleStackedRebaseCascade)issue-closed.yml→propagate_dependencies(kind: issue-closed)(covershandleIssueClosedpropagation half)pr-dependency-markers.ymlonpull_request: [opened, edited, synchronize]→pr_dependency_markersop (covershandlePrDependencyMarkers)The remaining work is purely:
event-handlers.tsso theprFlowcapability inmain.tscan call them without thelegacy*alias indirectionevent-handlers.tsThat is the same move Phase 6 (#1096) does as part of splitting
event-handlers.tsinto topical modules — Phase 6 already plans to relocatehandleIssueClosed/handlePrDependencyMarkers/handleStackedRebaseCascadetoworkflow/pr-flow.ts(new) alongside the other helpers.Closing this ticket against #1096 to avoid a redundant intermediate PR that just renames
legacyHandle*tohandle*and then has Phase 6 re-touch the same lines.Coverage note: the cap impls in
main.ts:3770-3801still route through the legacy aliases for now. No behavioural regression — the flow path is identical end-to-end. Phase 6 lands the actual deletion + module split in one PR.