fix(channels): use live owner binding during wasm hot activation

[G7CNF]

Summary

• fix hot activation to resolve WASM channel owner_id from live settings (channels.wasm_channel_owner_ids.<name>) instead of only using the startup snapshot
• keep existing fast path via in-memory runtime owner map, then fall back to persisted settings
• add regression test for owner-id resolution path used during hot activation

Why

activate_wasm_channel() previously read owner bindings only from set_channel_runtime() state captured at startup. If owner binding changed after startup, hot-activated channels could miss owner_id and regress to pairing state.

Fixes #1052

Validation

• cargo fmt --all
• cargo test test_current_channel_owner_id_uses_runtime_state --quiet

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an issue where hot-activated WASM channels could lose their owner_id if the owner binding changed after the application's initial startup. The solution ensures that the system dynamically fetches the most current owner_id from live settings, improving the robustness of channel activation and preventing channels from regressing to a pairing state due to outdated owner information.

Highlights

• WASM Channel Owner ID Resolution: Implemented a fix for hot activation to resolve WASM channel owner_id from live settings, specifically channels.wasm_channel_owner_ids.<name>, instead of relying solely on the startup snapshot.
• Optimized Owner ID Lookup: Maintained an existing fast path for owner ID resolution via an in-memory runtime owner map, with a fallback mechanism to persisted settings if not found in memory.
• Regression Test Added: Included a new regression test to validate the owner-id resolution path used during hot activation, ensuring the fix behaves as expected.

Changelog

• src/extensions/manager.rs
  • Added a new asynchronous method current_channel_owner_id to retrieve the owner ID for a given channel name, first checking an in-memory runtime map and then falling back to persisted settings.
  • Modified the activate_wasm_channel method to utilize the new current_channel_owner_id for determining the owner ID during hot activation.
  • Removed the direct cloning of wasm_channel_owner_ids from the runtime guard, as the new method now handles its retrieval.
  • Introduced a new #[tokio::test] case, test_current_channel_owner_id_uses_runtime_state, to validate the correct resolution of channel owner IDs from runtime state.

Activity

• The author validated the changes by running cargo fmt --all to ensure code formatting compliance.
• The author confirmed the fix with cargo test test_current_channel_owner_id_uses_runtime_state --quiet, specifically targeting the new regression test.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly addresses the issue of resolving WASM channel owner IDs during hot activation by fetching them from live settings instead of relying on a startup snapshot. The introduction of current_channel_owner_id with a fast-path cache and a fallback to the database is a solid approach. The changes are well-contained and the logic is sound. I've added one suggestion to enhance the test coverage to ensure both the cache and database fallback paths are verified.

[G7CNF]

Addressed in commit 3b00d0d:

• added store-fallback coverage for current_channel_owner_id (libsql-backed test)
• rewrote new tests to return Result<(), String> with explicit error paths, which also satisfies the no-panics gate

[zmanian]

Review: Read owner binding live during WASM hot activation

Good fix. Owner binding was read from a stale snapshot taken when the runtime lock was acquired. If binding happened after (e.g., Telegram verification), the activation path missed it.

Positives:

• current_channel_owner_id() checks runtime state first, then falls back to database
• Removes wasm_channel_owner_ids from the destructured tuple, so it's never read from the snapshot
• Test coverage for both runtime fast-path and DB fallback (libsql feature-gated)
• Defensive string-to-i64 parsing for stored values

LGTM.