Does the beaker-plugin-safe-app free handles automatically once the URL changes? I have a test app that uses history.pushState internally and it seems after such a page switch the handles are invalid when calling the several window.safeApp functions.
Yes, the handles are freed upon page reload and tab closing.
1 Like
I see. However, by doing a pushState, the page is neither reloaded nor closed. Consider the following example (tested this in the browser):
(async () => {
const handle = await window.safeApp.initialise({ id: '1', name: '2', vendor: '3' })
history.pushState({}, 'page 2', '/page2')
setTimeout(() => {
// Somewhat later.
await window.safeApp.connect(handle) // 'Invalid handle: 63b3e...'
}, 1000)
})()
2 Likes
Fair point and good find, @bzee. Weâll have to look at how weâre doing this 
to avoid that.
In the meantime, can you try with hash history perchance? I donât think that will trigger the same events so might work.
1 Like
I am using a library that does the routing, and internally it uses pushState, with hashes. It still frees the handles.
Hey @bochaco, Iâm trying to add a new entry to the container of my app by using the function insert but the new entry doesnât persist when I call getOwnContainer->getEntries again. Note that I can see the new entry if I use the same md_handle, it just doesnât persist if I reload the md_handle.
Is it ok to add an entry to a container or should containers be used exclusively as files using the NFS API?
Iâm using the mock network btw, any idea?
Hey @DavidMtl, are you committing the mutation with applyEntriesMutation on the containerâs MD?
Ah okay, but according to the doc it should commit to the network directly.
So whatâs the difference between using safeMutableDataEntries.insert and safeMutableDataMutation.insert? Is mutation used when we need to do multiple changes within a single âtransactionâ?
2 Likes
Yes, that should be corrected.
Yes, thatâd be the case, if you want/need to populate the mutations object with several actions and then commit it to the network to make it more efficient.
2 Likes
What happens if applyEntriesMutation is never called?
The safe_client_libs manages an object cache in memory, so those changes are actually kept there until you send a request to commit them to the network.
This cache is intended not only for the purpose of trying to make a more efficient use of the network, but itâs also required for the FFI interfacing with the upper layers (e.g. the safe_app_nodejs lib/package). Every object is instantiated at the safe_client_libs layer, and the safe_app_nodejs just manages handles provided by it (they are kept within the Javascript objects the apps interact with, so itâs transparent to them). This is analogous to what happens between the browserâs safe_app plugin and the exposed DOM API.
2 Likes
You mean the doc or the behavior?
The doc, Iâm sorry about that.
3 Likes
So what do you expect to happen - out of memory error at some random point? Might be better to have a limit on the cache and throw a specific error that this has been reached, or to force a commit (probably not!)
And if the browser tab is reloaded before the call to applyEntriesMutation those changes are lost?
It would be useful to know the expected behaviours (in the docs).
Yes, the safe_client_libs has a size cap and itâs an LFU cache.
I wouldnât agree on the auto-commit in this case though, and it you are really unlucky to get your changes removed due to the LFU mechanism before you could commit them (which I think itâs not being unlucky but actually using a very inefficient app which keeps storing things in the cache without committing them, right? is my reasoning correctâŚ?) then you should get an error when trying to commit as you would be referencing objects/data that doesnât exist in the cache anymore.
Correct, because we clean all objects created by the app to prevent a mem leak caused by apps not freeing the objects by invoking the DOM API free functions.
1 Like
@happybeing, it sounds to me you are taking the discussion towards transactions for mutations/changes, is that right? 
Iâm not sure what you mean. Iâm just trying to clarify how things work - no agenda or significant opinions here. Itâs not something I know much about, hence the dumb questions! Thanks for taking time out to answer - as always.
I was just kidding, when replying I started thinking about how having transactions could be applicable to some of this scenarios, like if instead of keeping some changes on the cache you send them to the network but as part of a transaction, which could somehow be rolled-back if the app decided to, or when the tab is refreshed and the connection with the network lost. But Iâm also thinking that unless the app could recover an unfinished/uncommitted transaction, perhaps to continue acting on it, then the local cache should be good enough.
2 Likes
Hey @bochaco, the function authorise doesnât work anymore. In the API playground I run initialise then authorise and then it gets stuck there. Do you have the same problem on your side?
Hey @DavidMtl, I just gave it a try and itâs working for me. If you still have issues please provide a more detailed explanation of the steps you made on the playground tool. Also based on other post from you, I get you are building the browser yourself, just trying to narrow it down, can you please validate if the issue also happens with the browser we released?
2 Likes