Independent confirmation of the diagnosis in #1735, plus one issue with the fix as written.

Confirming the bug. We hit this in CI while bumping gh-ost from a 2026-05-14 build to v1.1.11. Our instant-DDL integration tests hung indefinitely — the migration stayed in running forever, never reaching a terminal state, exactly as described here. Worth noting for anyone triaging severity: the deadlock isn't reachable before #1699. shouldDecodeRowsEvent is what introduces a second contender for listenersMutex, so prior to that commit the blocked send merely leaked a goroutine. #1699 is what turns it into a hard hang, which makes this a regression for anyone on --attempt-instant-ddl upgrading across it.

The concern with the fix. drainGhostTableMigrated() uses a bare blocking receive:

func (mgtr *Migrator) drainGhostTableMigrated() {
	if mgtr.migrationContext.Resume {
		return
	}
	<-mgtr.ghostTableMigrated
}

The sender publishes via base.SendWithContext, which abandons the send when the context is cancelled. That means a bare receive on this channel becomes permanently unsatisfiable at exactly the moment the context is cancelled — so this trades the instant-DDL deadlock for an abort-path deadlock on the same channel.

Concretely: AttemptInstantDDL() retries up to --default-retries (#1667), and the heartbeat escalates to PanicAbort after its own successive-failure threshold. If the primary becomes unreachable during those retries, abort() cancels the context, the pending changelog send gives up, and drainGhostTableMigrated() then blocks forever — after the instant DDL may already have been applied. Migrate() never returns, its deferred teardown() never runs, and because the status/throttler tickers exit on finishedMigrating rather than on the context, the process stays alive logging a frozen status line.

Suggestion — mirror #1677 here:

func (mgtr *Migrator) drainGhostTableMigrated() error {
	if mgtr.migrationContext.Resume {
		return nil
	}
	select {
	case <-mgtr.ghostTableMigrated:
		return nil
	case <-mgtr.migrationContext.GetContext().Done():
		return mgtr.checkAbort()
	}
}

For what it's worth, I've opened #1758 applying the same treatment to the other remaining bare receive on this channel — the <-mgtr.ghostTableMigrated on the normal path in Migrate(). The two changes are complementary and touch adjacent lines, so they'll likely need light coordination on whichever lands second. Happy to fold this drain into #1758 instead if that's easier for review, or to help rebase this one (it's currently showing as conflicting).

I've pushed a more complete fix to #1758 ; if that merges, this PR can be closed