gastownhall/beads · warning

%s (%s)

Error message

%s (%s)

What it means

This warning surfaces partial-success warnings returned by the tracker from a successful CreateIssue call (created.Warnings). The remote issue was created, but a follow-up operation inside the tracker adapter (e.g. setting state, labels, or metadata after creation) failed. The message prints the tracker's warning text followed by the local issue ID.

Source

Thrown at internal/tracker/engine.go:1103

					return stats, nil
				}
				continue
			}

			// Update local issue with external ref
			ref := e.Tracker.BuildExternalRef(created)
			updates := map[string]interface{}{"external_ref": ref}
			if err := e.Store.UpdateIssue(ctx, issue.ID, updates, e.Actor); err != nil {
				e.warn("Failed to update external_ref for %s: %v", issue.ID, err)
				stats.Errors++
				// Note: issue WAS created externally, so we still count Created
				// but also flag the error so the user knows the link is broken
			}
			// Surface any partial-success warnings from the create (e.g. a
			// follow-up state change that failed) through the sync result so a
			// degraded push is visible rather than silently swallowed.
			for _, w := range created.Warnings {
				e.warn("%s (%s)", w, issue.ID)
			}
			// Remember what we just pushed so the next sync can skip the fetch.
			e.recordPushHash(ctx, issue, ref)
			stats.Created++
		} else if !opts.CreateOnly || forceIDs[issue.ID] {
			// Update existing external issue
			extID := e.Tracker.ExtractIdentifier(extRef)
			if extID == "" {
				stats.Skipped++
				continue
			}

			// Check if update is needed
			if !forceIDs[issue.ID] {
				// Fast path: if the local content is unchanged since the last
				// successful push, the remote must already match it, so skip the
				// fetch entirely. This is what keeps a no-op `--push-only` run
				// from issuing one GET per issue (gastownhall/beads#4214).

View on GitHub (pinned to 71377f2769)

Solutions

1. Read the warning text to see which follow-up step failed (e.g. a status change).
2. Check the tracker API token scopes/permissions cover the follow-up operation (state changes, field updates).
3. Verify the tracker's workflow allows transitioning the issue directly to the requested state after creation.
4. Update the tracker adapter/integration to the latest version if the remote API changed.
5. Manually fix the affected issue state in the tracker and re-run `bd sync` to confirm clean pushes.

Example fix

// before: token with only issue:create scope
// after: grant the token write access to issue state fields
// Linear: add issues:update scope; Jira: add 'Modify Reporter'/'Edit Issues' permission

// after sync, inspect and address partial-success warnings
stats, err := engine.Sync(ctx, opts)
for _, w := range stats.Warnings {
    log.Printf("push warning: %s", w) // e.g. "failed to set status (bd-7)"
}
// fix scopes/workflow in the tracker, then re-run sync

When it happens

Trigger: e.Tracker.CreateIssue returns a created issue whose Warnings slice is non-empty — typically when a post-create step in the adapter (state transition, custom field set) fails after the issue itself was created.

Common situations: Linear/Jira/GitHub adapters that create the issue but fail to apply a status change due to insufficient token scopes; tracker-side workflow rules rejecting a state transition; deprecated custom fields on the remote tracker.

Related errors

• Failed to update %s in %s: %v
• Failed to re-import %s: %v
• dolt path is not executable
• database not available: %w
• initializing Azure DevOps tracker: %w

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