Repository navigation
Conversation
Replace the MethodChannel transport with dart:ffi bindings generated by the pigeon C++ FFI generator (git ref 1e63f1b5), following the video_player migration in flutter-tizen#1207. - Generate the C++ FFI bindings (messages_ffi.{h,cc}), the Dart FFI bindings (messages.g.ffi.dart), and the ffigen config from pigeons/messages.dart - Marshal every FFI entry point onto the platform thread's GLib main context via a MainContextDispatcher, preserving the thread affinity the messenger-based implementation provided - Register the FFI API at plugin construction and tear it down in Dispose() - Add an integration test that round-trips sync and async FFI calls - Bump version to 0.2.0 Co-Authored-By: Cline SR
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fe0675ddd3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| pigeon_in_x5f_app_x5f_purchase_x5f_tizen_tizen_x2f_src_x2f_messages_x5f_ffi_x2e_h_free_buffer(reply); | ||
| return; | ||
| } | ||
| on_reply(reply_id, reply); |
There was a problem hiding this comment.
Guard pending FFI replies against isolate teardown
If a hot restart occurs while a billing request is pending, the native plugin and BillingManager retain the response lambda, but its on_reply points to the NativeCallable.listener created by the destroyed Dart isolate. A delayed billing response then invokes an invalid callback trampoline here, which can terminate the process. TearDownInAppPurchaseApiFfi() only clears the API and dispatcher pointers; it does not invalidate callbacks already stored by BillingManager. Cancel or invalidate pending native replies before isolate teardown, or use a port-based reply transport that safely rejects replies to a dead isolate.
Useful? React with 👍 / 👎.
…sters After a hot restart the old isolate is destroyed while native reply callbacks survive in BillingManager. A late billing response would then invoke a NativeCallable of the dead isolate and can crash the process. Add an initialize() host API that resets pending BillingManager callbacks, and call it from register() in the root isolate so stale replies are invalidated as soon as the new isolate registers the plugin, before any new request is made. Co-Authored-By: Cline SR
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 80f0056498
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| is_available_callback_ = nullptr; | ||
| buy_item_callback_ = nullptr; | ||
| get_product_list_callback_ = nullptr; | ||
| get_purchase_list_callback_ = nullptr; | ||
| verify_invoice_callback_ = nullptr; |
There was a problem hiding this comment.
Reject stale native completions when resetting callbacks
When a hot restart occurs while a billing call is pending, initialize() clears these slots without cancelling the underlying native request, whose user_data still references the same BillingManager. If its reply arrives before a replacement call, handlers such as OnAvailable enter their null-callback branch and invoke the empty std::function, throwing std::bad_function_call out of the native callback. If a replacement call has already populated the slot, the old reply instead completes the new call with the wrong result, and the actual new reply then encounters the empty slot. Cancel the underlying operations or associate completions with per-request contexts/generations so stale replies cannot invoke or clear the current callback.
Useful? React with 👍 / 👎.
…e replies - Add meta to dependencies: pigeon v29 generates an import of package:meta in messages.g.dart, and pub publish --dry-run requires every imported package to be declared. - Change the null-callback branches of the billing reply handlers to log instead of invoking the empty std::function, which throws std::bad_function_call and terminates the process when a stale reply arrives after initialize() has reset the pending callbacks. Co-Authored-By: Cline SR
Main changes:
Fix: #1172