feat: add Spark SDK debug logging patch

[ditto-agent]

Summary

• Patches @buildonspark/spark-sdk@0.7.1 with debug logs gated behind globalThis.__SPARK_SDK_DEBUG__
• Sets the global flag from DEBUG_LOGGING_SPARK feature flag in entry.client.tsx
• Logs cover the full SDK internals: stream setup, reconnection retries, event processing, getBalance() (owned vs available vs fresh coordinator leaves), and syncWallet()

Context

Investigating stale Spark balance on mobile after receive. Root cause hypothesis: the SDK's gRPC event stream dies during mobile background, retries may reconnect but don't call syncWallet(), so the leaf cache misses transfers from the gap period. getBalance().owned reads from stale cache while .available is fresh from the coordinator.

These logs (prefixed [Spark SDK]) will confirm whether:

• The stream disconnects/reconnects on mobile background
• Events are missed during the gap
• owned diverges from available after reconnection

Files changed

• patches/@buildonspark%2Fspark-sdk@0.7.1.patch — SDK debug logging patch
• app/entry.client.tsx — sets globalThis.__SPARK_SDK_DEBUG__ from feature flag
• package.json / bun.lock — patch registration

Test plan

• Enable DEBUG_LOGGING_SPARK flag, open app
• Verify [Spark SDK] logs appear in console (stream setup, getBalance calls)
• Background the app on mobile for >30s, then foreground
• Send a payment to the app while backgrounded
• Check logs for stream error/retry sequence and whether owned diverges from available
• Verify no logs appear when flag is disabled

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agicash	Ready	Preview, Comment	Mar 31, 2026 11:56am

[orveth]

looks good overall — clean gating pattern, no sensitive data logged, patch registration is correct.

one thing caught my eye: in the getBalance() patch, owned and incoming are assigned before addLeaves/evictStaleAvailable but the original code called getOwnedBalance()/getIncomingBalance() after those calls (inline in the return). does the ordering matter here? if eviction changes what those return, the debug patch would report pre-eviction values. might want to move those two assignments below evictStaleAvailable to match the original call timing.

otherwise this is a clean diagnostic patch — good to go once that's checked.

[jbojcic1]

looks good overall — clean gating pattern, no sensitive data logged, patch registration is correct.

one thing caught my eye: in the getBalance() patch, owned and incoming are assigned before addLeaves/evictStaleAvailable but the original code called getOwnedBalance()/getIncomingBalance() after those calls (inline in the return). does the ordering matter here? if eviction changes what those return, the debug patch would report pre-eviction values. might want to move those two assignments below evictStaleAvailable to match the original call timing.

otherwise this is a clean diagnostic patch — good to go once that's checked.

@orveth I think you are wrong. The patch logs values before and after those calls, unless I am missing something

[jbojcic1]

will close and reopen because gh actions seem stuck

[supabase]

This pull request has been ignored for the connected project hrebgkfhjpkbxpztqqke because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[jbojcic1]

@gudnuf I am merging this (and merged one more before) without waiting for your approval because these are just minor log changes