gastownhall/beads · error

loading attachment subgraph %s: %w

Error message

loading attachment subgraph %s: %w

What it means

Wrapped error from loadTemplateSubgraph while fetching the template subgraph of an --attach proto during `bd mol pour`. After the attachment issue itself resolves and loads fine, walking its full child subgraph failed, so the pour transaction aborts before any cloning happens. This is a database/storage-layer failure, not a validation error.

Source

Thrown at cmd/bd/mol_proxied_server.go:96

			issue    *types.Issue
			subgraph *TemplateSubgraph
		}
		var attachments []attachmentInfo
		for _, attachArg := range in.attachArgs {
			attachID, err := utils.ResolvePartialID(ctx, w, attachArg)
			if err != nil {
				return pourProxiedResult{}, "", fmt.Errorf("resolving attachment ID %s: %w", attachArg, err)
			}
			attachIssue, err := w.GetIssue(ctx, attachID)
			if err != nil {
				return pourProxiedResult{}, "", fmt.Errorf("loading attachment %s: %w", attachID, err)
			}
			if !isProto(attachIssue) {
				return pourProxiedResult{}, "", fmt.Errorf("%s is not a proto (missing '%s' label)", attachID, MoleculeLabel)
			}
			attachSubgraph, err := loadTemplateSubgraph(ctx, w, attachID)
			if err != nil {
				return pourProxiedResult{}, "", fmt.Errorf("loading attachment subgraph %s: %w", attachID, err)
			}
			attachments = append(attachments, attachmentInfo{attachID, attachIssue, attachSubgraph})
		}

		vars := applyVariableDefaults(vars, subgraph)

		var attachSubgraphs []*TemplateSubgraph
		for _, a := range attachments {
			attachSubgraphs = append(attachSubgraphs, a.subgraph)
		}
		if err := checkPourVars(subgraph, attachSubgraphs, vars); err != nil {
			return pourProxiedResult{}, "", err
		}

		if in.dryRun {
			var previews []pourAttachPreview
			for _, a := range attachments {
				previews = append(previews, pourAttachPreview{title: a.issue.Title, steps: len(a.subgraph.Issues)})

View on GitHub (pinned to 71377f2769)

Solutions

  1. Check the wrapped inner error (%w) to see whether it is 'not found' vs a storage error; fix the underlying cause first
  2. Run `bd doctor` to verify database integrity and repair broken dependency references
  3. Re-sync the database: `bd dolt pull` if the attachment molecule was created on another machine
  4. If the attachment molecule is broken and unrecoverable, remove it from the --attach list and recreate the molecule

Example fix

// before
bd mol pour bd-123 --attach bd-999   // fails: loading attachment subgraph bd-999: issue not found: bd-1001
// after
bd doctor && bd dolt pull            // repair/sync, then retry the pour
bd mol pour bd-123 --attach bd-999
Defensive patterns

Strategy: validation

Validate before calling

// Inspect the attachment molecule before pouring
bd mol show <attachID>
// Verify all children are present:
bd list | grep <attachID>

Type guard

func isAttachSubgraphLoadable(err error) bool {
    return err == nil // dry-run the pour first; a nil error means all attachment subgraphs loaded
}

Try / catch

if err := runPourProxiedServer(ctx, in); err != nil {
    var inner error = errors.Unwrap(err)
    log.Printf("attachment subgraph load failed: %v", inner)
    // fall back to pouring without the broken attachment
}

Prevention

When it happens

Trigger: Run `bd mol pour <proto> --attach <id>` where the attachment issue passes isProto() (has the molecule label) but loadTemplateSubgraph(ctx, w, attachID) fails to load its descendant issues — e.g. a DB query error, corrupted dependency links, or a storage connection failure inside the transaction.

Common situations: Corrupt or partially-synced Dolt database where dependency rows reference missing issues; the attach target's children were deleted out-of-band; transient storage/driver errors while the UOW transaction is open.

Related errors


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