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

85 lines
3.1 KiB
Markdown

# 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:
```text
019ef9a5-5efc-7500-9a7d-4e7ec6920e84
```
The next input received by the parent thread was the child callback:
```text
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:
```text
investigations/2026-06-24-thread-notification-wakeup/test-1-child-result.md
```
Recorded child result:
```text
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:
```text
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.