change the timing to remove PropertyChanged event #498
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary for English Speakers:
This issue addresses a problem with the ReactivePropertySlim class in the ReactiveProperty library. When updating from version 8.2.0 to 9.0.0, an InvalidOperationException occurs in the PropertyChanged event after the object is disposed. The proposed solution changes the timing of the event subscription removal to avoid this exception. The event is now unsubscribed before the OnCompleted method is executed, ensuring a more natural order and preventing exceptions caused by unrelated property change notifications.
いつもお世話になっております。
ReactiveProperty を 8.2.0 から 9.0.0 以降にアップデートすると、ReactivePropertySlim 周りでたまに InvalidOperationException が発生する事があるという問題が手元で起こっています。
例外の発生箇所は、SimplePropertyObservable.Subscription.PropertyChanged 関数でした。
例外発生時、確かに _isDisposed は true でした。また、e.PropertyName と _propertyName は別の名前でした。
しかし、本来、Dispose 関数が呼び出されて _isDisposed が true になっている場合、PropertyChanged イベントも remove されているはずで、PropertyChanged 関数は呼び出されないはずです。
おそらく、_isDisposed が true になってからイベントが購読解除されるまでの OnCompleted の処理中にイベントが発生してしまっていると推測します。
これをなるべく避けるために、イベントの購読解除を OnCompleted よりも先に行うように変更しました。OnCompleted の実行前に OnNext が走らないようにするのは、むしろ自然な順序かと思います。
加えて、今回起こっている問題の場合、発火されたプロパティ変更通知は Dispose された Subscription オブジェクト宛てのものではありませんでした。無関係の変更通知で例外を発生させるのは変な挙動かなと思います。
そのため、_isDisposed のチェックとプロパティ名のチェック順を逆にしました。
issue を立てずにいきなりプルリクエストを送る形になってしまいましたが、一考して頂けると幸いです。