video-workbench/investigations/2026-06-24-thread-notificat.../test-1-report.md

3.1 KiB

Test 1 Report

Date: 2026-06-24

Status

  • Result: pass for the minimal callback wakeup test.
  • Parent observed report time: 2026-06-24T20:44:15.6912187+08:00
  • Parent polling used after dispatch: no.

Parent-Side Observation

The parent session ended its dispatch turn after sending the formal start message to child thread:

019ef9a5-5efc-7500-9a7d-4e7ec6920e84

The next input received by the parent thread was the child callback:

Video Workbench wakeup Test 1 callback from child thread 019ef9a5-5efc-7500-9a7d-4e7ec6920e84.
If this message activated the parent thread without polling, record the result in investigations/2026-06-24-thread-notification-wakeup/test-1-report.md.
Child result path: investigations/2026-06-24-thread-notification-wakeup/test-1-child-result.md
Parent thread id: 019ef999-07d2-7333-99b4-d5d2da040406

This indicates the parent thread was activated by the child callback path, not by parent-side polling.

Child-Side Evidence

Child result file:

investigations/2026-06-24-thread-notification-wakeup/test-1-child-result.md

Recorded child result:

status: slept 2 minutes and sent callback
parent_thread_id: 019ef999-07d2-7333-99b4-d5d2da040406
child_thread_id: 019ef9a5-5efc-7500-9a7d-4e7ec6920e84
sleep duration: 120 seconds
callback method: Codex app send_message_to_thread
callback target: 019ef999-07d2-7333-99b4-d5d2da040406
callback sent / failed: sent
any tool limitation: send_message_to_thread was not initially exposed; tool_search exposed it successfully

Finding

For a minimal two-minute test, a clean visible child Codex thread can wake the parent thread by calling send_message_to_thread with the parent thread id.

The parent thread id can be obtained by the parent session at runtime through Codex app thread-list observation, under the user-controlled precondition that only one active main Video Workbench session is running.

Limits

This test does not yet prove the full production slide workflow should replace polling immediately.

Remaining questions:

  • whether the same callback behavior remains reliable after 30-60 minute child runs;
  • whether callback delivery behaves the same when the child has heavy tool use, image generation, or internal SubAgents;
  • whether a production child session should send the callback only after writing child-session-handoff.md and passing the completion gate;
  • how to handle callback send failure without falling back to hidden parent polling;
  • whether the parent should still keep a very long safety timeout outside normal workflow execution.

Workflow Implication

Candidate replacement for routine parent polling:

parent observes current parent_thread_id
-> parent creates clean child session
-> parent sends task packet containing parent_thread_id and callback contract
-> parent ends turn
-> child writes compact handoff after completion gate
-> child calls send_message_to_thread(parent_thread_id, callback)
-> parent wakes and reads compact handoff

Do not promote this into docs/workflows/slide-task-orchestration.md until at least one production-shaped child-session test confirms the callback after a real slide package.