mirror of
https://github.com/bytedance/deer-flow.git
synced 2026-10-26 21:26:39 +00:00
* fix(skillscan): keep a live client handle through a branch that rebinds it later The instance-client signal dropped every name a compound statement could bind before walking any of its parts, so an outbound call that really happened first disappeared when a later statement in that same body rebound the name (issue #4296, case 1). Dropping up front is what keeps a benign skill from being hard-blocked for the parts that can *follow* a sibling's rebinding -- a `finally` after a handler replaced the handle, an `else` after a loop body -- so those keep it. Parts that cannot follow a sibling (an `if`/`elif`/`else` branch, the one `match` case that runs, a `try` body, a loop body) are now walked with the enclosing handle intact and apply their own bindings in source order, the rule the top level already uses. Names the statement binds as it dispatches -- a loop target, an `except ... as` name, a `match` capture -- stay dropped before every part. * fix(skillscan): walk a compound header before dropping its dispatch bindings A loop target, an `except ... as` name and a `match` capture bind only after that header has been evaluated, so dropping them first hid a real sink written in the header itself: `for s in s.post(...)` with `s` a live handle reported nothing, while the same call under a differently named target was found. Move the drop to after the header loop and before the parts, which is all `_branching_parts` needs; the body still starts with those names gone, so the loop-value case stays unreported. Raised in review on #7128. Pins the two header shapes, the inverse that keeps the body conservative, and the three paths the review called out as unpinned: the mutually-exclusive two-level `if`/`elif` case, a `while` body, and a `try` `else` after a body rebind. --------- Co-authored-by: Willem Jiang <willem.jiang@gmail.com>