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
- Check the wrapped inner error (%w) to see whether it is 'not found' vs a storage error; fix the underlying cause first
- Run `bd doctor` to verify database integrity and repair broken dependency references
- Re-sync the database: `bd dolt pull` if the attachment molecule was created on another machine
- 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
- Run `bd mol pour ... --dry-run` first; it loads every attachment subgraph without side effects
- Run `bd doctor` periodically to catch dangling dependency edges early
- Keep the database synced (`bd dolt pull`) before molecule operations spanning machines
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.