gastownhall/beads · error

journal dependency removals for batched wisp delete: %w

Error message

journal dependency removals for batched wisp delete: %w

What it means

This error wraps failures from issueops.RecordDependencyRemovalsForIssuesInTx, which journals dependency (edge) removals for the wisps about to be deleted while their source snapshots are still readable. This journaling must succeed before the rows are deleted so consumers can learn which edges disappeared; a failure here rolls back the whole batch transaction.

Source

Thrown at internal/storage/dolt/wisps.go:451

	affectedIssues, affectedWisps, aerr := issueops.AffectedByDeletionInTx(ctx, tx, nil, ids)
	if aerr != nil {
		return 0, fmt.Errorf("affected by batched wisp delete: %w", aerr)
	}

	// Resolve WHICH wisps this batch actually removes before the DELETE runs:
	// afterwards they are gone, and RowsAffected reports a count, not a set.
	// GC hands this path ids it scanned earlier, so an already-collected wisp is
	// a routine case, and a phantom delete record would tell a consumer to drop
	// a bead this transaction never touched.
	deletedIDs, err := issueops.ExistingIssueIDsInTableInTx(ctx, tx, "wisps", ids)
	if err != nil {
		return 0, fmt.Errorf("resolve existing wisps for batch delete: %w", err)
	}
	// Edges are journaled before the rows go, while their source snapshots can
	// still be read.
	if err := issueops.RecordDependencyRemovalsForIssuesInTx(ctx, tx, deletedIDs); err != nil {
		return 0, fmt.Errorf("journal dependency removals for batched wisp delete: %w", err)
	}

	inClause, args := doltBuildSQLInClause(ids)

	//nolint:gosec // G201: inClause contains only ? markers
	result, err := tx.ExecContext(ctx,
		fmt.Sprintf("DELETE FROM wisps WHERE id IN (%s)", inClause),
		args...)
	if err != nil {
		return 0, fmt.Errorf("failed to batch delete wisps: %w", err)
	}
	rowsAffected, _ := result.RowsAffected()

	// The batched wisp delete surface carries no actor, so the rows record none.
	for _, id := range deletedIDs {
		if err := issueops.RecordDeleteInTx(ctx, tx, id, ""); err != nil {
			return 0, err
		}

View on GitHub (pinned to 71377f2769)

Solutions

1. Keep batches small — the library already batches at 200; if you call internals directly, stay within that limit to respect Dolt's 10s write timeout
2. Check Dolt server responsiveness (disk I/O, replication lag) and retry once healthy
3. Verify journal/dependencies tables exist with the expected schema; apply pending migrations
4. Inspect the wrapped cause for a specific driver error (lock timeout, ctx deadline) and tune timeouts accordingly

// Go: confirm journal tables exist before GC
var one int
if err := db.QueryRowContext(ctx, "SELECT 1 FROM issue_events LIMIT 1").Scan(&one); err != nil {
    return fmt.Errorf("journal table missing or unreachable: %w", err)
}

_, err := store.DeleteWisps(ctx, ids)
if err != nil {
    if strings.Contains(err.Error(), "journal dependency removals") {
        // journal write failed: check Dolt write timeout / server health before retry
        log.Printf("edge journaling failed, batch rolled back: %v", err)
    }
    return err
}

When it happens

Trigger: DeleteWisps path on wisps that have dependency edges, when the INSERTs that journal edge removals fail: Dolt write timeout (batch too large or server slow), connection loss, cancelled context, or a missing/mismatched journal or dependencies schema.

Common situations: Large GC batches hitting Dolt's 10s write timeout on a slow disk or remote server; database migrated to a schema where journal tables are missing; concurrent writers causing lock contention on journal tables.

Related errors

• affected by batched wisp delete: %w
• ErrTransaction
• failed to begin transaction: %w
• failed to commit is_blocked repairs: %w
• failed to begin transaction: %w

AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30). Data as JSON: /api/errors/13fd4a37f24bc153. Report an issue: GitHub.