moeru-ai/airi · error · ActionError

RESOURCE_MISSING

RESOURCE_MISSING

Error message

Failed to collect any ${type}

What it means

Thrown by the collectBlocks action (ActionError code RESOURCE_MISSING) when collectBlock returns 0 collected items. The action wraps mineflayer-embedded-toolkit's collectBlock; a zero result means no matching block was found in range, the bot could not path to any, or mining was interrupted. Context carries { type, requested, collected }.

Source

Thrown at integrations/minecraft/src/cognitive/action/llm-actions.ts:269

    },
  },
  {
    name: 'collectBlocks',
    description: 'Automatically collect the nearest blocks of a given type.',
    execution: 'async',
    // NOTICE: detach auto-follow before mining. The idle auto-follow reflex drives the same
    // mineflayer pathfinder as digging; if left attached it periodically re-points the bot at the
    // followed player, which both cancels navigation to the ore ("Path was stopped") and aborts the
    // in-progress bot.dig ("Digging aborted"), producing the stutter of repeated half-digs.
    followControl: 'detach',
    schema: z.object({
      type: z.string().describe('The block type to collect.'),
      num: z.number().int().describe('The number of blocks to collect.').min(1),
    }),
    perform: mineflayer => async (type: string, num: number) => {
      const collected = await collectBlock(mineflayer, type, num)
      if (collected <= 0) {
        throw new ActionError('RESOURCE_MISSING', `Failed to collect any ${type}`, { type, requested: num, collected })
      }
      return `Collected [${type}] x${collected}`
    },
  },
  {
    name: 'mineBlockAt',
    description: 'Mine (break) a block at a specific position. Do NOT use this for regular resource collection. Use collectBlocks instead.',
    execution: 'async',
    // NOTICE: detach auto-follow before mining (same reason as collectBlocks) so the follow reflex
    // cannot interrupt bot.dig mid-break.
    followControl: 'detach',
    schema: z.object({
      x: z.number().describe('The x coordinate.'),
      y: z.number().describe('The y coordinate.'),
      z: z.number().describe('The z coordinate.'),
      expected_block_type: z.string().optional().describe('Optional: expected block type at the position (e.g. oak_log). If provided and mismatched, the action fails.'),
    }),
    perform: mineflayer => async (x: number, y: number, z: number, expected_block_type?: string) => {

View on GitHub (pinned to 27111382b4)

Solutions

  1. Move the bot to a biome/area where the block type actually generates before reissuing.
  2. Confirm the type alias is recognized by matchesBlockAlias; use the canonical minecraft block name.
  3. Clear inventory space or stash items so pickups can register.
  4. Ensure the chunk is loaded (bot is standing in it) before collecting.
Defensive patterns

Strategy: try-catch

Try / catch

try {
  await performAction({ tool: 'collectBlocks', params: { type, num } })
} catch (e) {
  if (e.code === 'RESOURCE_MISSING')
    // reposition bot to a biome where the block spawns, then retry
  throw e
}

Prevention

When it happens

Trigger: Requesting a block type not present near the bot (e.g. 'diamond_ore' when underground without any); the block alias resolves to nothing matchesBlockAlias can map; pathfinding failed for all candidates; inventory full so pickup never registered.

Common situations: LLM asks to collect a resource in a biome where it does not spawn; chunk not loaded so blockAt scans find nothing; bot encumbered/falling so pathfinder cannot route; alias mismatch between the LLM's term and the registered block names.

Related errors

AI-assisted analysis of moeru-ai/airi@27111382b4 (2026-08-12). Data as JSON: /api/errors/406e352eb5dbd3d9. Report an issue: GitHub.