Skip to content
Merged
4 changes: 4 additions & 0 deletions .beads/interactions.jsonl
Original file line number Diff line number Diff line change
Expand Up @@ -191,3 +191,7 @@
{"id":"int-d11b256e","kind":"field_change","created_at":"2026-08-10T02:42:16.8074426Z","actor":"G.Hirpara","issue_id":"daz-script-server-okpk","extra":{"field":"status","new_value":"closed","old_value":"open","reason":"Added AxisRemap to dazpy/math3.py: apply_vec3/apply_quat/apply_bbox with reflection rejection, Y_UP_TO_Z_UP preset, exported from dazpy package. Wired into tests.py unit runner."}}
{"id":"int-27eb72b4","kind":"field_change","created_at":"2026-08-11T02:07:34.4536775Z","actor":"G.Hirpara","issue_id":"daz-script-server-063","extra":{"field":"status","new_value":"closed","old_value":"open","reason":"Won't fix, after implementation review. The already-shipped pre-check busy detection (commit 720736f, on master) already turns the original unbounded hang into a bounded, self-correcting ~15s slow-but-correct response — no data loss, no wrong result, just latency. A working bounded-wait backstop was implemented and independently verified concurrency-correct (race-free CAS ceiling, sound thread/promise lifetimes, Qt6-portable), but final review surfaced a real behavioral hazard: on timeout the queued main-thread call is NOT cancelled (Qt has no API for this) and keeps running, so the 503 the client receives is misleading (the operation is still executing), and dazpy's retry_on_busy could re-run it — a double-execution risk strictly worse than the slow-but-correct wait it replaces. The default 20s timeout also exceeds the one measured gap (~15s), so it offers little value against the observed problem and is really speculative insurance against a worse, never-observed wedged-main-thread case. Decision: the tradeoff isn't worth it as scoped; keep the existing pre-check detection only. The implementation (branch feature/studio-busy-handling, commits 680b267..467ea7b) is not merged to master. Revisit only if a genuinely unbounded hang is observed in practice, with a design that avoids the discard-and-maybe-retry hazard (e.g. never reusing a retry-safe error code for a timeout that doesn't actually stop the underlying work)."}}
{"id":"int-dfa45616","kind":"field_change","created_at":"2026-08-11T02:11:53.6096817Z","actor":"G.Hirpara","issue_id":"daz-script-server-nfdr","extra":{"field":"status","new_value":"closed","old_value":"in_progress","reason":"Docs updated (README + math3.rst), AxisRemap gained __eq__/__hash__, removed dead _matrix/_det slots (kept as locals), added 24-permutation property test covering all _mat3_to_quat branches. inverse() deliberately left as separate future item per issue note."}}
{"id":"int-fac2f1b8","kind":"field_change","created_at":"2026-08-15T02:41:37.054825Z","actor":"G.Hirpara","issue_id":"daz-script-server-3l5o","extra":{"field":"status","new_value":"closed","old_value":"in_progress","reason":"Fixed: connected DzRenderMgr::renderFinished(bool) as a guaranteed exit path for the render busy state, since it fires on render failure even when DzScene::renderFinished(DzRenderer*) is blocked behind DAZ Studio's modal error dialog. Verified builds against both SDK4 and SDK6."}}
{"id":"int-441bfd61","kind":"field_change","created_at":"2026-08-15T03:42:33.7102845Z","actor":"G.Hirpara","issue_id":"daz-script-server-eaub","extra":{"field":"status","new_value":"closed","old_value":"in_progress","reason":"Added AsyncRequestManager::failStaleRunning(), a 5-min-cadence watchdog that marks any request RUNNING past ASYNC_STALE_RUNNING_TIMEOUT_MIN (30 min default) as FAILED with a diagnostic message, plus a guard in markCompleted() so a late real completion can't flip an already-terminal (timed-out) request back to completed/cancelled. Live-verified on DAZ Studio 4: with timings temporarily dropped to 1 min for a fast test, a render stuck behind an Error Saving modal correctly auto-failed while the modal was still up, and stayed failed after the modal was later dismissed. Production timings (30/5 min) restored and reinstalled before commit."}}
{"id":"int-78fdac5e","kind":"field_change","created_at":"2026-08-15T03:46:42.3174912Z","actor":"G.Hirpara","issue_id":"daz-script-server-q0l4","extra":{"field":"status","new_value":"closed","old_value":"in_progress","reason":"cancelJson()/cancelRenderJson() now mark the request CANCELLED immediately on cancel of a RUNNING request (same as the QUEUED branch), instead of leaving status='running' when killRender() has nothing to kill. Best-effort killRenderOnMainThread() is still invoked for render requests. markCompleted()'s existing terminal-state guard (from the eaub stale-running fix) prevents a late real completion from flipping status back. Added tests/test_api.py::test_async_cancel_running_request_reaches_terminal_status (not live-verified this session — DAZ Studio wasn't running)."}}
{"id":"int-1436dca1","kind":"field_change","created_at":"2026-08-15T03:59:50.3718077Z","actor":"G.Hirpara","issue_id":"daz-script-server-j1pg","extra":{"field":"status","new_value":"closed","old_value":"in_progress","reason":"Researched, decided not to implement. See issue notes: no public SDK hook exists to intercept the Iray render-error modal before it appears (raised by closed-source dzirayrenderer.dll, outside SDK surface); no global silent/suppress-dialogs flag on DzApp reachable from a loaded plugin; the only remaining option (a generic Qt dialog-auto-click watchdog) was rejected as too risky -- it could misfire on a legitimate interactive dialog a human is looking at, trading a bounded, well-understood degradation (already fixed by 3l5o/eaub/q0l4: 503 fail-fast + terminal status within 30 min) for an unbounded new failure mode. Recommended external process-level watchdog (restart DAZ Studio on /health timeout) if unattended headless pipelines become a real requirement."}}
Loading
Loading