Files
ai-workflow-skill/docs/tests/inbox-skill/blocked-worker-timeout-without-reply-through-bundled-cli.md
T

3.4 KiB

Case: blocked-worker-timeout-without-reply-through-bundled-cli

Test Type

This is a forward-test and a timeout-path skill validation.

The goal is to verify that a blocked worker using the bundled inbox skill sees the correct wait-reply timeout behavior when no answer arrives.

Purpose

Validate that all of the following can be true at the same time:

  • a worker can use the skill to fetch, claim, and block a real thread
  • the worker can call wait-reply through the bundled CLI
  • the leader intentionally does not answer
  • the worker receives the expected timeout contract instead of silently succeeding
  • the thread remains in a blocked state with the question preserved

Preconditions

  • skill path exists: SKILL_PATH=skills/inbox
  • bundled CLI executable exists: SKILL_PATH/assets/inbox
  • use an empty temporary directory TMPDIR
  • test database path is TMPDIR/coord.db

Agent Topology

  • leader
  • worker-a

Inputs

Leader Prompt

Use $inbox at SKILL_PATH to act as leader on SQLite DB TMPDIR/coord.db. Only coordinate through the bundled inbox CLI from the skill. Workflow: 1) initialize the DB, 2) send exactly one task to worker-a, 3) monitor until worker-a asks one blocked question, 4) intentionally do not reply, 5) stop after confirming the thread is still blocked. Do not use ordinary chat to coordinate with the other agent.

Worker Prompt

Use $inbox at SKILL_PATH to act as worker-a on SQLite DB TMPDIR/coord.db. Only coordinate through the bundled inbox CLI from the skill. Workflow: 1) fetch pending work, 2) claim it, 3) send a blocked update with one precise question, 4) call wait-reply with a short timeout, 5) stop after reporting the timeout result exactly as observed. Do not use ordinary chat to coordinate with the other agent.

Execution Parameters

  • use the shared execution contract from README.md
  • override the worker-side wait timeout to a short interval such as 10s
  • keep the default cleanup policy

Execution Steps

  1. Inject the same skills/inbox/ skill into both real agents
  2. Point both agents at the same database path TMPDIR/coord.db
  3. Launch leader and worker-a in parallel
  4. Wait for both agents to finish
  5. Resolve THREAD_ID from the agent outputs or inbox history
  6. Independently run the validation commands from the main thread

Validation Commands

SKILL_PATH/assets/inbox --db TMPDIR/coord.db --json show --thread THREAD_ID
SKILL_PATH/assets/inbox --db TMPDIR/coord.db --json list --status blocked

Expected Outcomes

  • leader successfully creates one thread for worker-a
  • worker-a successfully fetches and claims it
  • worker-a emits one blocked question
  • the blocked question is preserved at least in message.payload_json.question
  • worker-a runs wait-reply and receives the no-match timeout contract
  • the leader emits no answer message
  • the final thread status remains blocked

Assertions

  • the worker reports exit code 10 and JSON error code no_matching_work from wait-reply
  • show includes the blocked question message
  • show.data.messages[*].payload_json.question contains Should logging go to stdout or stderr?
  • show does not include any answer message
  • list --status blocked returns the thread

Cleanup

  • use the default cleanup policy from README.md
  • if the run fails, retain TMPDIR and coord.db for replay and manual inspection