fix: resolve async completion in ConditionalBindingHandler

[phillipc]

Summary

Fixes two bugs in ConditionalBindingHandler identified in typescript-code-review-findings-5.md (Critical Finding 1).

• Non-rendering branches never resolved: if: false, ifnot: true, and with: null all hit the empty-branch path in render() without calling completeBinding(), leaving the AsyncBindingHandler promise permanently unresolved. Any await applyBindings(...) would hang indefinitely.

• Premature completion with async descendants: renderAndApplyBindings used await applyBindingsToDescendants(...), but that function returns a BindingResult synchronously — not a Promise. The await resolved immediately without waiting for async child bindings to finish. Fix follows the DescendantBindingHandler pattern: call without await, use bound.completionPromise when !bound.isSync, and short-circuit this.bindingCompletion = bound for the sync case so the binding isn't unnecessarily tracked as async.

Test plan

• bun run build passes
• bunx vitest run packages/binding.if — new regression tests for if: false, ifnot: true, with: null completion
• bunx vitest run packages/bind/spec/bindingCompletionPromiseBehavior.ts — new test for if: true with async descendants
• bunx vitest run — full suite (290 files, no regressions)

[coderabbitai]

Warning

Rate limit exceeded

@phillipc has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 21 minutes and 2 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0c2ac882-c1e0-4dbb-9ee0-5d0f89d8c959

📥 Commits

Reviewing files that changed from the base of the PR and between 7590b48 and 6f94126.

📒 Files selected for processing (6)

• .changeset/fix-conditional-binding-async-completion.md
• packages/bind/spec/bindingCompletionPromiseBehavior.ts
• packages/binding.if/spec/ifBehaviors.ts
• packages/binding.if/spec/ifnotBehaviors.ts
• packages/binding.if/spec/withBehaviors.ts
• packages/binding.if/src/ConditionalBindingHandler.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Review rate limit: 0/1 reviews remaining, refill in 21 minutes and 2 seconds.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[brianmhunt]

Adversarial review

Fix is faithful to the canonical DescendantBindingHandler pattern. Both bugs verified: applyBindings outer Promise hangs pre-fix on no-render branches (handler's bindingCompletion never resolves), and the bogus await applyBindingsToDescendants(...) resolved before async descendants completed. All four added tests would have failed pre-fix.

Worth verifying while here:

• Coverage gap: no test for if: false chained with else sibling (else binding chain). Same code path benefits from the fix; one extra spec line confirms it doesn't regress.

Out of scope (notes for the record):

• ConditionalBindingHandler now contains a near-verbatim copy of DescendantBindingHandler.applyBindingsToDescendants logic. Worth a refactor pass later — not blocking this PR.
• Changeset target (@tko/binding.if patch) is correct. Timing change is a bug fix, not a breaking contract.

LGTM modulo the optional else-chain test.