Handling of disposable items

[dockeratso]

Suggestion:

Items (objects that fulfill the IDisposable) that pass the ObserveOn operator should be disposed when a subscription is disposed.

Similar with Sample and other rx classes.

How can disposable items being handled to avoid memory leaks?

Suggestions?

[idg10]

When you say this:

Items (objects that fulfill the IDisposable) that pass the ObserveOn operator

What do you mean by "pass the ObserveOn operator"?

Operators are invoked. They are methods, not objects, so I don't know what it would mean to "pass" an operator. (You can pass a method as a delegate of course, but I can't think of any API in Rx.NET that expects you to pass a delegate that refers to an operator.)

Please can you provide a short code example illustrating this scenario, and explain which object you think that Rx.NET should be disposing?

[dockeratso]

Hi. Here is an example written in .Net 10 as unit test. The code just shows that the disposables are being disposed of the GC. In our application we are using dispsables (images with native memory) which would like to be disposed to avoid memory leaks. The pipeline of different image transformations handles images in generated by a high fps source. Problems like disposing and cloning of images required some linqs to be rewritten and also subjects too. Tried earlier with reference counting using standard byte[] with GC but then we got severe memory usage peaks. Best regards, Anders class DisposableItem : IDisposable { private bool disposedValue; private int id; public DisposableItem(int id) { this.id = id; } public override string ToString() { return $"DisposableItem {id}"; } protected virtual void Dispose(bool disposing) { if (!disposedValue) { if (disposing) { } else { Debug.WriteLine($"Finalizer called for item {id}, disposing unmanaged resources"); } disposedValue = true; } } ~DisposableItem() { this.Dispose(disposing: false); } public void Dispose() { // Do not change this code. Put cleanup code in 'Dispose(bool disposing)' method this.Dispose(disposing: true); GC.SuppressFinalize(this); } } [TestMethod] public async Task TestingDisposablesInRxObservableOn() { using var subject = new Subject<DisposableItem>(); var subscription = subject .ObserveOn(TaskPoolScheduler.Default). Select(item => { Debug.WriteLine($"Handled item {item}"); Task.Delay(100).Wait(); return item; }) .Subscribe( item => { Debug.WriteLine($"Received item {item}"); item.Dispose(); }, ex => Debug.WriteLine($"Error: {ex}"), () => Debug.WriteLine("Completed")); for (int i = 0; i < 10; i++) { subject.OnNext(new DisposableItem(i)); } subscription.Dispose(); await Task.Delay(2500).ConfigureAwait(false); GC.Collect(); } Output: The thread '.NET Long Running Task' (21020) has exited with code 0 (0x0). Finalizer called for item 0, disposing unmanaged resources Finalizer called for item 1, disposing unmanaged resources Finalizer called for item 2, disposing unmanaged resources Finalizer called for item 3, disposing unmanaged resources Finalizer called for item 9, disposing unmanaged resources Finalizer called for item 8, disposing unmanaged resources Finalizer called for item 7, disposing unmanaged resources Finalizer called for item 6, disposing unmanaged resources Finalizer called for item 5, disposing unmanaged resources Finalizer called for item 4, disposing unmanaged resources The thread '.NET Long Running Task' (30132) has exited with code 0 (0x0). The program '[21620] testhost.exe' has exited with code 0 (0x0)

…

________________________________ Från: Ian Griffiths ***@***.***> Skickat: den 28 maj 2026 09:06 Till: dotnet/reactive ***@***.***> Kopia: Anders Frisk ***@***.***>; Author ***@***.***> Ämne: Re: [dotnet/reactive] Handling of disposable items (Issue #2320) [https://avatars.githubusercontent.com/u/334181?s=20&v=4]idg10 left a comment (dotnet/reactive#2320)<#2320 (comment)> When you say this: Items (objects that fulfill the IDisposable) that pass the ObserveOn operator What do you mean by "pass the ObserveOn operator"? Operators are invoked. They are methods, not objects, so I don't know what it would mean to "pass" an operator. (You can pass a method as a delegate of course, but I can't think of any API in Rx.NET that expects you to pass a delegate that refers to an operator.) Please can you provide a short code example illustrating this scenario, and explain which object you think that Rx.NET should be disposing? — Reply to this email directly, view it on GitHub<#2320?email_source=notifications&email_token=APJIRKAU3K2NAZH7K6A3I5T447QQBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJWGE2TOMBSHEY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4561570291>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/APJIRKF3WTBF2N5EBY5J3Z3447QQBAVCNFSM6AAAAACZOFWMEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKNRRGU3TAMRZGE>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/APJIRKB5TGCOT5UIX2JBNQ3447QQBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJWGE2TOMBSHEY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/APJIRKBOLQZXUTQHFPWOFEL447QQBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJWGE2TOMBSHEY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

________________________________ Guaranteed Confidentiality You are hereby formally notified that all information contained in this communication and any attachments shall be deemed strictly confidential and privileged unless explicitly stated otherwise. Please note that your use of confidential information may be governed, and restricted, by a non-disclosure agreement. The information contained in this communication and any attachments is disclosed for the sole use of the intended recipient(s). If you are not the intended recipient, you are hereby formally notified that any unauthorized review, use, disclosure or distribution of this message is prohibited. Please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments.

________________________________

[idg10]

So to try and summarise what you're asking for: when IDisposable items flowing through an Rx subscription, you want them to be disposed automatically? But only if they pass through the ObserveOn operator.

Looking at your example, I think that the scenario motivating your suggestion is that some of your items never get delivered to the subscriber because the subscription got torn down before the ObserveOn operator had time to deliver all items. (In single-threaded code, this wouldn't happen because the loop that calls subject.OnNext(...) would deliver all notifications synchronously, meaning that all items are already delivered before you have a chance to unsubscribe. But by introducing ObserveOn(TaskPoolScheduler.Default), these notifications all now all queue up, to be executed at whatever rate the scheduler can manage. subject.OnNext(...) doesn't wait for them to get through. (Or to be more precise, it has no idea they've not been sent all the way through because ObserveOn returns from OnNext as soon as it has queued up the item.) And since your code calls subscription.Dispose() immediately after that loop without leaving any time for the scheduler to deliver the work, this means you are cancelling the subscription before it has time to deliver even 1 item. This is why your subscriber's item.Dispose() doesn't run.)

So if I've understood correctly, the mental model you have here is: if ObserveOn fails to deliver items, it becomes responsible for their lifetime (because the subscriber that would normally Dispose them won't be able to), which is why you believe ObserveOn should be calling Dispose. Have I understood?

Although I have some sympathy with the idea—if Rx decided not to deliver something, then at least it could clean up after itself—there are some problems with this idea. The biggest is that this is a radical move away from a basic assumption in Rx, which is that Rx operators themselves don't modify the items that pass through them. (Some operators invoke application-supplied callbacks, which are of course free to do whatever they like. So you could use Select in a way that did change the state of items passing through, e.g. by calling Dispose, but that would be application code changing the items, not Rx itself.)

More specifically, as far as I'm aware nothing in Rx currently ever calls Dispose on a value that was delivered into Rx via OnNext. (This is just a specific case of the more general principle that Rx doesn't do anything to the values that it delivers.) There are situations in which Rx will automatically Dispose a subscription, but that's a) because subscriptions are special Rx-isms, b) something that will typically only happen if Rx created the subscription (e.g., in a chain of Rx-defined operators, calls to Dispose will cascade through the subscriptions set up all the way down the chain, in the mirror image of the process in which Rx created that chain of subscriptions in the first place), and c) not an example of a payload event being Disposed (i.e., this is not an example of some T in an IObservable<T> being disposed by Rx, which is the new thing you're proposing).

So this would be a radical shift away from a basic principle of Rx. It would also be a major breaking change: there are plenty of scenarios in which IDisposable values might be propagated all the way through an Rx subscription and not be disposed immediately. (E.g., imagine you had an IObservable<IDisposable> reporting things that will need to be disposed when some particular window closes. If we suddenly starting calling Dispose immediately after these things were delivered we'd break any application trying to use Rx in this way.)

There's also a practical problem: ObserveOn doesn't know whether the items it delivers via OnNext actually make it all the way through the subscription chain. When multiple operators are involved, tearing down a subscription is not instantaneous. When the application has called Dispose to shut down a subscription, but that call to Dispose has not yet returned, we are in an in-between 'unsubscribe-in-progress' sort of a state. We necessarily shut down the operators in sequence. So it's possible that the ObserveOn operator will have invoked OnNext to pass on a value at a time when as far as it knows, the subscription is still running, but for the subscription teardown to stop it from reaching the end subscriber. (This possibility is unavoidable in a multithreaded world: it is part of the nature of ObserveOn, that it can't possibly know whether the subscriber at the end of the chain of operators will still be active by the time an OnNext call reaches it.)

E.g., your example causes the Select operator to block for a while (using Task.Delay(100).Wait(), which is an unsafe thing to do, but essentially amounts to Thread.Sleep(100), because it will just block the thread for 100ms...or deadlock because calling Wait on a Task is risky...but let's assume your code gets away with that). It's completely possible that when ObserveOn delivered a value to its upstream receiver (Select, here) the subscription was still up and running, but that in that 100ms for which your Select callback blocks the thread, the application's main thread calls subscription.Dispose(), which will begin the subscription shutdown process, meaning that your Subscribe callback never runs. And yet ObserveOn did actually deliver the value, so how's it supposed to know that the value was never received? (The call it made to OnNext will return as normal, with no indication that it got stopped in transit due to unsubscription.) You might think that ObserveOn could check whether the subscription is still running after the call to OnNext, but that's unreliably: it's possible that the value did actually make it through to the receiver, and that the unsubscription happened after that but before control returns to the ObserveOn operator. Even if it detects that unsubscription happened during its call to the downstream OnNext, It can never know for certain whether the last subscriber in the chain actually saw the message.

Perhaps we could solve this by always calling Dispose on every item, regardless of whether it got through or not, because IDispose implementations are supposed to tolerate double disposal (if we ignore the fact that this is a major breaking change) but there's yet another problem! This design does not cope well with multiple subscribers. A single source may have any number of subscribers. Even if you've only made a single call to ObserveOn, multiple calls to Subscribe on the resulting IObservable actually set up multiple completely separate chains of subscribers. (We talk about 'an operator' but if you subscribed to your example twice, each operator would create 2 instances of the internal type that it uses to represent a subscription in progress.)

The effect is that when your loop calls subject.OnNext(...) the Subject<T> actually calls OnNext multiple times, once on each of its downstream subscribers. So now, if ObserveOn starts disposing values after it forwards them it's going to mess things up for any other subscribers. You'll start getting ObjectDisposedExceptions. (You might not actually notice this if you're using the TaskPoolScheduler because of an unfortunate decision in .NET 4.0 to make the task pool silently swallow unhandled exceptions by default!)

This, by the way, is one of the reasons behind the basic design principle that Rx never does anything to the values you pass to OnNext. Its job is just to convey them to their destination; it is for application code to decide if and how to act on those values (including whether and when to Dispose them). It pretty much has to be this way because a single value can end up being dispatched through Rx many times over. Multicast behaviour (like you're getting here with Subject<T>, but also with the Multicast operator and related operators) does it, but operators like Window and Buffer can result in the same value being delivered to a subscriber several times over even if you have only a single subscriber.

Another objection I have to this idea if that it joins together two concerns that I believe should be independent, but which your suggestion ties together. Today ObserveOn has exactly once concern: scheduling. (More precisely, it delivers all notifications (OnNext, OnError, OnComplete) to subscribers through whatever IScheduler you pass it.) Your change would give it an additional responsibility: disposal of all values that pass through an ObserveOn operator. How would that work if I don't want this new disposal behaviour you've described? Your suggestion would mean I'm no longer able to use ObserveOn with values that implement IDisposable if I don't want them to be disposed immediately. And if I did want this new disposal behaviour but I don't want to get a scheduler involved, how would I use it?

(Perhaps we could answer these questions by adding parameters to ObserveOn to opt into it, but this doesn't solve the basic problem that it's not really possible for ObserveOn to do this reliably in general, for the reasons already discussed.)

One final issue: one of the things I've learned in 2 and a half years since taking over maintenance of Rx is what a bad idea it is for an application to depend on the details of subscription shutdown behaviour. It's inherently messy for reasons that are fundamentally unavoidable once multiple threads are involved. The guarantees that Rx normally makes do not apply once unsubscription is underway. And because Rx operators can't in general know whether the notifications they delivered actually made it all the way through to the final subscriber in the chain, they really can't make the kind of guarantees you're looking for, unfortunately.

If I have misunderstood your scenario, then I apologise. But if not, I hope you can understand why I don't think we should add the feature you suggest into Rx.

So, how would I solve the problem?

Your example implies that you have something that is creating objects that need to be disposed, and that this feeds objects into an Rx-based processing pipeline. And apparently you need to be able to call Dispose on that Rx subscription while everything is still in progress, but still reliably be able to ensure everything gets disposed. By using ObserveOn(TaskPoolScheduler.Default) you've introduced non-deterministic behaviour into the Rx part of all this, which is why you can't solve this entirely with Rx.

Here's what I'd do. I'd have something that keeps track of all the 'in-flight' disposable objects. This might be something as simple as a ConcurrentBag<T>. Each time your subscriber calls Dispose() on one of these, remove it from the ConcurrentBag<T>. When you need to shut down the description you can then iterate through this bag of objects and Dispose them all (which you'd do in a loop after calling subscription.Dispose()).

[dockeratso]

Hi and thanks for you answer. I was curious and I wanted know if there a good way to use Rx in the world of disposable items (in the pipelines). As you pointed out there many problems related how to handle disposable items without letting the GC taking care of disposing. At the moment we have require the items to be IClonable and IDisposable. Subject implementation has been modified to always send a clone to each observable. Select dispose input item and create a new to return (if item has to be changed). Subscribe callback ends up disposing the item in the end. Other used linq rx filters are also being adapted. Our items are megapixel images and standard memory handling is to heave for the GC with standard Rx but this modification solves the memory issue. I will think of your idea about using a concurrent bag if it is applicable. Thanks. Skickat från min iPhone 4 juni 2026 kl. 15:07 skrev Ian Griffiths ***@***.***>:  [https://avatars.githubusercontent.com/u/334181?s=20&v=4]idg10 left a comment (dotnet/reactive#2320)<#2320 (comment)> So to try and summarise what you're asking for: when IDisposable items flowing through an Rx subscription, you want them to be disposed automatically? But only if they pass through the ObserveOn operator. Looking at your example, I think that the scenario motivating your suggestion is that some of your items never get delivered to the subscriber because the subscription got torn down before the ObserveOn operator had time to deliver all items. (In single-threaded code, this wouldn't happen because the loop that calls subject.OnNext(...) would deliver all notifications synchronously, meaning that all items are already delivered before you have a chance to unsubscribe. But by introducing ObserveOn(TaskPoolScheduler.Default), these notifications all now all queue up, to be executed at whatever rate the scheduler can manage. subject.OnNext(...) doesn't wait for them to get through. (Or to be more precise, it has no idea they've not been sent all the way through because ObserveOn returns from OnNext as soon as it has queued up the item.) And since your code calls subscription.Dispose() immediately after that loop without leaving any time for the scheduler to deliver the work, this means you are cancelling the subscription before it has time to deliver even 1 item. This is why your subscriber's item.Dispose() doesn't run.) So if I've understood correctly, the mental model you have here is: if ObserveOn fails to deliver items, it becomes responsible for their lifetime (because the subscriber that would normally Dispose them won't be able to), which is why you believe ObserveOn should be calling Dispose. Have I understood? Although I have some sympathy with the idea—if Rx decided not to deliver something, then at least it could clean up after itself—there are some problems with this idea. The biggest is that this is a radical move away from a basic assumption in Rx, which is that Rx operators themselves don't modify the items that pass through them. (Some operators invoke application-supplied callbacks, which are of course free to do whatever they like. So you could use Select in a way that did change the state of items passing through, e.g. by calling Dispose, but that would be application code changing the items, not Rx itself.) More specifically, as far as I'm aware nothing in Rx currently ever calls Dispose on a value that was delivered into Rx via OnNext. (This is just a specific case of the more general principle that Rx doesn't do anything to the values that it delivers.) There are situations in which Rx will automatically Dispose a subscription, but that's a) because subscriptions are special Rx-isms, b) something that will typically only happen if Rx created the subscription (e.g., in a chain of Rx-defined operators, calls to Dispose will cascade through the subscriptions set up all the way down the chain, in the mirror image of the process in which Rx created that chain of subscriptions in the first place), and c) not an example of a payload event being Disposed (i.e., this is not an example of some T in an IObservable<T> being disposed by Rx, which is the new thing you're proposing). So this would be a radical shift away from a basic principle of Rx. It would also be a major breaking change: there are plenty of scenarios in which IDisposable values might be propagated all the way through an Rx subscription and not be disposed immediately. (E.g., imagine you had an IObservable<IDisposable> reporting things that will need to be disposed when some particular window closes. If we suddenly starting calling Dispose immediately after these things were delivered we'd break any application trying to use Rx in this way.) There's also a practical problem: ObserveOn doesn't know whether the items it delivers via OnNext actually make it all the way through the subscription chain. When multiple operators are involved, tearing down a subscription is not instantaneous. When the application has called Dispose to shut down a subscription, but that call to Dispose has not yet returned, we are in an in-between 'unsubscribe-in-progress' sort of a state. We necessarily shut down the operators in sequence. So it's possible that the ObserveOn operator will have invoked OnNext to pass on a value at a time when as far as it knows, the subscription is still running, but for the subscription teardown to stop it from reaching the end subscriber. (This possibility is unavoidable in a multithreaded world: it is part of the nature of ObserveOn, that it can't possibly know whether the subscriber at the end of the chain of operators will still be active by the time an OnNext call reaches it.) E.g., your example causes the Select operator to block for a while (using Task.Delay(100).Wait(), which is an unsafe thing to do, but essentially amounts to Thread.Sleep(100), because it will just block the thread for 100ms...or deadlock because calling Wait on a Task is risky...but let's assume your code gets away with that). It's completely possible that when ObserveOn delivered a value to its upstream receiver (Select, here) the subscription was still up and running, but that in that 100ms for which your Select callback blocks the thread, the application's main thread calls subscription.Dispose(), which will begin the subscription shutdown process, meaning that your Subscribe callback never runs. And yet ObserveOn did actually deliver the value, so how's it supposed to know that the value was never received? (The call it made to OnNext will return as normal, with no indication that it got stopped in transit due to unsubscription.) You might think that ObserveOn could check whether the subscription is still running after the call to OnNext, but that's unreliably: it's possible that the value did actually make it through to the receiver, and that the unsubscription happened after that but before control returns to the ObserveOn operator. Even if it detects that unsubscription happened during its call to the downstream OnNext, It can never know for certain whether the last subscriber in the chain actually saw the message. Perhaps we could solve this by always calling Dispose on every item, regardless of whether it got through or not, because IDispose implementations are supposed to tolerate double disposal (if we ignore the fact that this is a major breaking change) but there's yet another problem! This design does not cope well with multiple subscribers. A single source may have any number of subscribers. Even if you've only made a single call to ObserveOn, multiple calls to Subscribe on the resulting IObservable actually set up multiple completely separate chains of subscribers. (We talk about 'an operator' but if you subscribed to your example twice, each operator would create 2 instances of the internal type that it uses to represent a subscription in progress.) The effect is that when your loop calls subject.OnNext(...) the Subject<T> actually calls OnNext multiple times, once on each of its downstream subscribers. So now, if ObserveOn starts disposing values after it forwards them it's going to mess things up for any other subscribers. You'll start getting ObjectDisposedExceptions. (You might not actually notice this if you're using the TaskPoolScheduler because of an unfortunate decision in .NET 4.0 to make the task pool silently swallow unhandled exceptions by default!) This, by the way, is one of the reasons behind the basic design principle that Rx never does anything to the values you pass to OnNext. Its job is just to convey them to their destination; it is for application code to decide if and how to act on those values (including whether and when to Dispose them). It pretty much has to be this way because a single value can end up being dispatched through Rx many times over. Multicast behaviour (like you're getting here with Subject<T>, but also with the Multicast operator and related operators) does it, but operators like Window and Buffer can result in the same value being delivered to a subscriber several times over even if you have only a single subscriber. Another objection I have to this idea if that it joins together two concerns that I believe should be independent, but which your suggestion ties together. Today ObserveOn has exactly once concern: scheduling. (More precisely, it delivers all notifications (OnNext, OnError, OnComplete) to subscribers through whatever IScheduler you pass it.) Your change would give it an additional responsibility: disposal of all values that pass through an ObserveOn operator. How would that work if I don't want this new disposal behaviour you've described? Your suggestion would mean I'm no longer able to use ObserveOn with values that implement IDisposable if I don't want them to be disposed immediately. And if I did want this new disposal behaviour but I don't want to get a scheduler involved, how would I use it? (Perhaps we could answer these questions by adding parameters to ObserveOn to opt into it, but this doesn't solve the basic problem that it's not really possible for ObserveOn to do this reliably in general, for the reasons already discussed.) One final issue: one of the things I've learned in 2 and a half years since taking over maintenance of Rx is what a bad idea it is for an application to depend on the details of subscription shutdown behaviour. It's inherently messy for reasons that are fundamentally unavoidable once multiple threads are involved. The guarantees that Rx normally makes do not apply once unsubscription is underway. And because Rx operators can't in general know whether the notifications they delivered actually made it all the way through to the final subscriber in the chain, they really can't make the kind of guarantees you're looking for, unfortunately. If I have misunderstood your scenario, then I apologise. But if not, I hope you can understand why I don't think we should add the feature you suggest into Rx. So, how would I solve the problem? Your example implies that you have something that is creating objects that need to be disposed, and that this feeds objects into an Rx-based processing pipeline. And apparently you need to be able to call Dispose on that Rx subscription while everything is still in progress, but still reliably be able to ensure everything gets disposed. By using ObserveOn(TaskPoolScheduler.Default) you've introduced non-deterministic behaviour into the Rx part of all this, which is why you can't solve this entirely with Rx. Here's what I'd do. I'd have something that keeps track of all the 'in-flight' disposable objects. This might be something as simple as a ConcurrentBag<T>. Each time your subscriber calls Dispose() on one of these, remove it from the ConcurrentBag<T>. When you need to shut down the description you can then iterate through this bag of objects and Dispose them all (which you'd do in a loop after calling subscription.Dispose()). — Reply to this email directly, view it on GitHub<#2320?email_source=notifications&email_token=APJIRKGDGE3WLE4O433AH7346FYBLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRSGI2DEMJXGE3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4622421716>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/APJIRKHW2VP6FJG5ACVWDK346FYBLAVCNFSM6AAAAACZOFWMEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DMMRSGQZDCNZRGY>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/APJIRKBYLWXG65X3IJ44VWD46FYBLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRSGI2DEMJXGE3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/APJIRKAQH7OPD77PTHVCRUT46FYBLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRSGI2DEMJXGE3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

…

________________________________ Guaranteed Confidentiality You are hereby formally notified that all information contained in this communication and any attachments shall be deemed strictly confidential and privileged unless explicitly stated otherwise. Please note that your use of confidential information may be governed, and restricted, by a non-disclosure agreement. The information contained in this communication and any attachments is disclosed for the sole use of the intended recipient(s). If you are not the intended recipient, you are hereby formally notified that any unauthorized review, use, disclosure or distribution of this message is prohibited. Please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments.

________________________________