CONCURRENT TOOLS · JOIN AND TIMEOUTS
Concurrent tools: isolate failures before joining results
Run four tool calls on a small thread pool, make one fail, hang or stall, and see what the join returns and when.
Event trace
Computed data
Final metrics
Modeled on Java CompletableFuture semantics without running Java: tasks start in submission order on the first free thread, a timeout is measured from submission and fails the future without freeing the thread, and allOf() completes only after every future settles. The request deadline returns an error with no partial results. Thread interruption and retries are not modeled.
One exception, no results
Four calls share a pool of 4 threads: the Stock-status call, weather (300 ms), calendar (500 ms) and maps (800 ms). By default the order call throws after 200 ms and Join strategy is allOf(...).join(). The join waits for every future, then rethrows at 800 ms and discards three good results: RESULTS LOST, 0/4. Choose Per-tool handle() with a fallback: ISOLATED, 3/4 at 800 ms.
A call that never fails
Choose Never returns. Both joins wait until the 3000 ms Request deadline and return nothing: DEADLINE EXCEEDED. A fallback runs only when a future fails, and a call without a timeout never fails. Set Per-tool timeout to 1000 ms with the per-tool join: ISOLATED, 3/4 at 1000 ms. Answers after 3500 ms behaves the same way; with allOf and a 5000 ms deadline it returns all four at 3500 ms.
Threads are not freed by a timeout
Keep Never returns with the 1000 ms timeout and set Thread pool size to 2. The timed-out order call keeps its thread, so weather, calendar and maps share one thread; maps starts at 800 ms and times out at 1000: STARVED, 2/4. With one thread nothing else ever starts: STARVED, 0/4. A Per-tool timeout of 100 ms fails even healthy calls that started at once: TIMEOUT TOO TIGHT.
Pool size without faults
With Answers in 400 ms and a single thread the calls run in sequence and finish at 2000 ms; a 1000 ms deadline then fails them all. The table lists when each call starts and settles, its outcome and whether it reached the response.
Replay and limits
Any change recomputes the run and rewinds it; the Complete-run preview states the outcome at once. Play and Pause walk through the events, Next event jumps one event, Restart rewinds, Speed runs from 0.25x to 2x and Inspection time seeks from 0 to 60 seconds, where the outcome and final metrics appear. Modeled on Java CompletableFuture semantics without running Java: tasks start on the first free thread in submission order and a timeout is measured from submission. Thread interruption and retries are not modeled.