gastownhall/beads · error

loading spawned mol: %w

Error message

loading spawned mol: %w

What it means

Wrapped error from w.GetIssue on spawnResult.NewEpicID. Cloning the proto subgraph succeeded, but re-loading the freshly created epic (mol root) immediately afterwards failed. This happens only when the pour included --attach arguments, since the spawned mol must be loaded before attachments can be bonded into it.

Source

Thrown at cmd/bd/mol_proxied_server.go:134

			renderPourDryRun(protoID, subgraph, vars, in.assignee, in.attachType, previews)
			return pourProxiedResult{}, "", nil
		}

		spawnResult, err := cloneSubgraphInto(ctx, w, subgraph, CloneOptions{
			Vars:     vars,
			Assignee: in.assignee,
			Actor:    actor,
			Prefix:   types.IDPrefixMol,
		})
		if err != nil {
			return pourProxiedResult{}, "", fmt.Errorf("pouring proto: %w", err)
		}

		totalAttached := 0
		if len(attachments) > 0 {
			spawnedMol, err := w.GetIssue(ctx, spawnResult.NewEpicID)
			if err != nil {
				return pourProxiedResult{}, "", fmt.Errorf("loading spawned mol: %w", err)
			}
			for _, attach := range attachments {
				bondResult, err := bondProtoMolAttachInto(ctx, w, attach.subgraph, attach.issue, spawnedMol, in.attachType, vars, "", actor, false, true)
				if err != nil {
					return pourProxiedResult{}, "", fmt.Errorf("attaching %s: %w", attach.id, err)
				}
				totalAttached += bondResult.Spawned
			}
		}

		return pourProxiedResult{spawn: spawnResult, totalAttached: totalAttached, attachCount: len(attachments)},
			fmt.Sprintf("bd: mol pour %s", protoID), nil
	})
	if err != nil {
		return HandleError("%v", err)
	}
	if res.spawn == nil {
		return nil

View on GitHub (pinned to 71377f2769)

Solutions

1. Retry the pour; the transaction aborts atomically so no orphaned molecule remains
2. Check the inner error for 'not found' vs I/O failure — 'not found' suggests a read-visibility or concurrency bug worth reporting
3. Ensure no concurrent `bd` process is mutating molecules while pouring
4. Update to the latest beads version, as read-after-write visibility inside UOW transactions may be fixed upstream

if err := runPourProxiedServer(ctx, in); err != nil {
    if strings.Contains(err.Error(), "loading spawned mol") {
        // transient read-after-write issue; retry once
        err = runPourProxiedServer(ctx, in)
    }
}

When it happens

Trigger: Run `bd mol pour <proto> --attach ...` where the clone step returned a NewEpicID but a subsequent GetIssue for that ID fails — e.g. the ID is not yet visible to reads inside the same transaction (isolation/visibility bug) or a storage read error occurs.

Common situations: Storage backend read-after-write inconsistency; concurrent process deleted or modified the mol between create and read; transient driver failure mid-transaction.

Related errors

• loading attachment subgraph %s: %w
• pouring proto: %w
• loading proto %s: %w
• loading proto: %w
• loading attachment %s: %w

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