Invalid MutableData permission set handle

I ran into problems when doing this in Alpha-2 network

// Create Self Permissions
            using (var categorySelfPermSetH = await MDataPermissions.NewAsync())
                await Task.WhenAll(
                    MDataPermissionSet.AllowAsync(categorySelfPermSetH, MDataAction.kInsert),
                    MDataPermissionSet.AllowAsync(categorySelfPermSetH, MDataAction.kUpdate),
                    MDataPermissionSet.AllowAsync(categorySelfPermSetH, MDataAction.kDelete),
                    MDataPermissionSet.AllowAsync(categorySelfPermSetH, MDataAction.kManagePermissions));

this threw an exception:

"Invalid MutableData permission set handle"

so, some investigation to do there. (That part has not worked before, it is part of a re-implementation based on the SAFE Email app).

Does anyone have any hints on what might be causing the exception?

Maybe because, if I’m interpreting correctly, you’re making 4 separate requests simultaneously to change permissions? Maybe try chaining the tasks one after the other instead?

1 Like

Thanks, but already tried it. It still gave the exception.

1 Like

Hi again. I still don’t know what could cause this error message.

So, the question is not what is causing it in this specific case (i.e. in my code), I would be more than happy with only some kind of explanation of what things generally cause this error message.
I think it could be quite helpful with that help only; i.e. to get an explanation of what kind of troubles you see could cause the error message. From there I can analyze my program to see if any such condition seem to be met. I might be able to identify the problem based on your description of how you have previously seen it occur.

If you think there are too many possible conditions, and want it more narrowed down to say anything, I have set up a small project (VS2017) which uses only the minimum necessary code to reproduce the error, it can be found here:

You can see that I already generated the encodedUrl, so it is to be pasted into the string on line 19 in class ReproErrorTest. Yes, this will log you in to my account on the live alpha 2 network, I figured I would try make it as easy as possible to help me here. So, this is the string:



So, you can just debug the method TestPermissionSet in class ReproErrorTest.cs, and step right through to line 42 in TestClass.cs. That is all that is necessary to see it in action.

Also provided, some of the points from this post:

Basic info as per the support questions template

- What application or program are you running?
SAFE.EventStore (or for your convenience SAFE.BugRepro), based on SafeMessages
It uses (included in SAFE.BugRepro) which is a .NET wrapper around the FFI libraries that I wrote.
I compiled safe_app and system_uri from alpha_2 branch.
SafeBrowser v0.6.0 for authorising app and getting encoded url.

- What’s the version number?

- What are the version numbers of the supporting dependencies that you are using locally? For example, Node.js, NPM, and Rust.
VS2017 Community

- Which operating system are you using and which version number?
Windows 10 Education in a Hyper-V VM (Microsoft Windows NT 6.2.9200.0)

- What steps did you follow when the error occurred and how can we reproduce it?
Basically I am running the same base code as SafeMessages, albeit extracted out and placed within another app.
The test project SAFE.BugRepro has extracted out what happens in the original project SAFE.EventStore.

I register the uri with SystemUri which I compiled from alpha_2 branch. Then I get an EncodedUrl from SafeBrowser (which is sent as argument to the application on the path I specified in AppInfo Exec property when installing the Uri).

There, the EncodedUrl is passed to HandleUrlActivationAsync of AppSession.cs, (it is the same code as in SafeMessages).
From there AppRegisteredAsync is called in class Session.cs, (containing exactly the same code as in SafeMessages).
There it calls
NativeBindings.AppRegistered(appId, authGrantedFfiPtr, NetObs, callback);
(which is also the exact same code, copied).

After this, I try to do the very first operation, which is to do the equivalent of what is done here:

This is done on line 42 in TestClass.cs, here:

And this is where the problem occurs (as per OP).

Q: Could someone please provide me with any information on what might be going wrong here?
Specifically, under what circumstances can this error "Invalid MutableData permission set handle" occur?
Or please let me know what more info I can give you so that you can help me out.

Hi @oetyng, this happens when the handle you provided (in this case for a MutableData PermissionsSet object) is not valid anymore in the safe_app lib, which means this object was removed from its internal objects cache and the handle cannot be used anymore to reference an object in the cache, or it was never a valid one and you are just providing anything that was never a valid handle.

From looking at the following line (without knowing the rest of the code), isn’t categorySelfPermSetH being assigned a Permissions object handle rather than a PermissionSet object handle?:

It sounds to me it should be:

using (var categorySelfPermSetH = await MDataPermissionSet.NewAsync())

Now, one thing you may want to be aware of (just in case you don’t know already) for this particular case, it is the fact that latest version of safe_app lib released last week (v0.5.0) doesn’t have PermissionSet objects anymore, so you won’t need to provide handles for setting permissions (insert/delete/update/manage permissions) on a Permissions object. Note that if you upgrade safe_app you’ll then need browser v0.8.x to generate a compatible auth URI.


Oh man… That was it. Gosh how simple!

Thanks a lot hey.

I was thinking something was screwed up on a less trivial manner than this. Especially since the tumble weed was rolling by this topic for so long.

Up until now I think around 100% of my support questions have been on this level, or slightly more “complicated”, so I haven’t really felt like waving my hands and shouting out loud, but maybe I should have :slight_smile: I mean, this was probably caught by you at first glance :slight_smile:

Again, thanks a lot.

Oh, and thanks for the heads-up on v0.5.0. I knew about it already, but I just wanted to go to the bottom on this problem, because I didn’t really know what the error was about, and didn’t want to dive into the code changes without having rooted that out.


This topic was automatically closed after 60 days. New replies are no longer allowed.