Testing I'm getting connection problems - any current SN issues?


You are right @happybeing , that wouldn’t explain it, unless you are leaking some handle/s and not freeing it before window.location.reload()…?..

If you have the chance, can you please give it a try to the following branch which I’m expecting to fix the problem?


Strange. I cloned and built but it won’t connect to SN (0.10.1 is fine though). The browser starts up but I’m getting Core error: Unexpected: Could not connect to the SAFE Network when I try to log in.

Linux 64 bit
nodejs 8.0.0

I did yarn run build && yarn run package

Trying yarn run burnthemall I’m getting some warnings (didn’t see these earlier)…

warning appdmg@0.4.5: The platform "linux" is incompatible with this module.
warning fsevents@1.1.3: The platform "linux" is incompatible with this module.
[1/2] ⢀ electron
[2/2] ⢀ fs-xattr: spawn args   '-Goutput_dir=.' ]
[-/2] ⢀ waiting...
[-/2] ⢀ waiting...
warning Error running install script for optional dependency: "/home/mrh/.cache/yarn/v1/npm-fs-xattr-0.1.17-ee943483c6fe9704a8f0e1476e8145a9886f8b0f: Command failed.\nExit code: 1\nCommand: sh\nArguments: -c node-gyp rebuild\nDirectory: /home/mrh/.cache/yarn/v1/npm-fs-xattr-0.1.17-ee943483c6fe9704a8f0e1476e8145a9886f8b0f\nOutput:\ngyp info it worked if it ends with ok\ngyp info using node-gyp@3.6.1\ngyp info using node@8.0.0 | linux | x64\ngyp info spawn /usr/bin/python2\ngyp info spawn args [ '/home/mrh/.nvm/versions/node/v8.0.0/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py',\ngyp info spawn args   'binding.gyp',\ngyp info spawn args   '-f',\ngyp info spawn args   'make',\ngyp info spawn args   '-I',\ngyp info spawn args   '/home/mrh/.cache/yarn/v1/npm-fs-xattr-0.1.17-ee943483c6fe9704a8f0e1476e8145a9886f8b0f/build/config.gypi',\ngyp info spawn args   '-I',\ngyp info spawn args   '/home/mrh/.nvm/versions/node/v8.0.0/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',\ngyp info spawn args   '-I',\ngyp info spawn args   '/home/mrh/.node-gyp/8.0.0/include/node/common.gypi',\ngyp info spawn args   '-Dlibrary=shared_library',\ngyp info spawn args   '-Dvisibility=default',\ngyp info spawn args   '-Dnode_root_dir=/home/mrh/.node-gyp/8.0.0',\ngyp info spawn args   '-Dnode_gyp_dir=/home/mrh/.nvm/versions/node/v8.0.0/lib/node_modules/npm/node_modules/node-gyp',\ngyp info spawn args   '-Dnode_lib_file=node.lib',\ngyp info spawn args   '-Dmodule_root_dir=/home/mrh/.cache/yarn/v1/npm-fs-xattr-0.1.17-ee943483c6fe9704a8f0e1476e8145a9886f8b0f',\ngyp info spawn args   '-Dnode_engine=v8',\ngyp info spawn args   '--depth=.',\ngyp info spawn args   '--no-parallel',\ngyp info spawn args   '--generator-output',\ngyp info spawn args   'build',\ngyp info spawn args   '-Goutput_dir=.' ]\nmodule.js:487\n    throw err;\n    ^\n\nError: Cannot find module 'nan'\n    at Function.Module._resolveFilename (module.js:485:15)\n    at Function.Module._load (module.js:437:25)\n    at Module.require (module.js:513:17)\n    at require (internal/module.js:11:18)\n    at [eval]:1:1\n    at ContextifyScript.Script.runInThisContext (vm.js:44:33)\n    at Object.runInThisContext (vm.js:116:38)\n    at Object.<anonymous> ([eval]-wrapper:6:22)\n    at Module._compile (module.js:569:30)\n    at evalScript (bootstrap_node.js:432:27)\ngyp: Call to 'node -e \"require('nan')\"' returned exit status 1 while in binding.gyp. while trying to load binding.gyp\ngyp ERR! configure error \ngyp ERR! stack Error: `gyp` failed with exit code: 1\ngyp ERR! stack     at ChildProcess.onCpExit (/home/mrh/.nvm/versions/node/v8.0.0/lib/node_modules/npm/node_module

The build completes but still won’t connect when I try to log in.


You must be just missing the crust.config file, you can copy from v0.10.1 or you can also find a copy under ./build/SAFE Browser.crust.config and you need to copy over as ./dist/safe-browser-v0.10.1-linux-x64/safe-browser.crust.config. You may want to also copy the log.toml file onto the same folder.


Ah, will try that thanks. I wondered about that and looked in the package directory and it does have two .configs but I guess not the real ones.

Might be useful to add to the README.md


I’ve tested your fork and it seems improved, but I’m still hitting the issue.

Previously I hit it after creating three new posts in succession, now I get to five. This includes a call to safeApp.free(appHandle) immediately before the window.location.reload(), and while my code is authorising and connecting multiple times, it should be freeing the appHandle before obtaining a new one.

So it may be a bug in my code, but also may still be an issue with the DOM API itself.

Worrryingly though, closing the tab and opening the website in a new one does not clear the problem. I’ll now try closing and waiting five minutes… still not cleared.

So closing the website’s tab is still not freeing the proxy connections, and it also looks like window.location.reload() is losing track of them. If I restart the browser all is good again.

On reflection, I’m not sure the fork is any different. I may have got to five new posts this time because I went straight to that and hadn’t done anything else since starting the browser.


@happybeing I just gave it a try with the one published at safe://plumetest (I cannot create posts but just browse using the existing ones) and what I see is that the app never frees any safeApp instance, I do see it’s freeing up some other objects (perhaps MD’s related objects handles), but not a safeApp object handle. Therefore, as you keep using the app and it reloads each time then one more connection is consumed. I also tried closing the tab and I do see all safeApp handles being freed by the browser, and I can open the app again and connect successfully on a new tab.

Could it be you are not using the right handle or overwriting the app handle you use to call freeApp() ?

Now, more in detail, what’s happening is that some time ago (I think it was also due to one of your apps, not sure if this same one) we made an adjustment to the mechanism that automatically frees handles when the page is reloaded, to only do it when the new page that is being loaded contains a different public Id, since the app was changing the URL via pushstate reloading with some relative paths (some more info here). Thus your app now is reloading each time without freeing the safeApp handle and with the same public Id, therefore the automatic mechanism is not kicking in untill you either load a page with different public Id, or close the tab.

PM me if you wanna go on a hangout, if you think it can help.


Thanks Gabriel, this gives me some lines of investigation, so very helpful.

Only the storage owner can create posts, which is not hard to set up for you, but it sounds like my code is probably not doing what I think so I’ll look into that.

I will probably not be able to follow up for a few days though, so expect a delay… and some peace from me at least :wink:

The code is working well enough for me to create a short demo so it’s not urgent. I’ll probably do that first. Thanks again.


A quick note @bochaco. I haven’t looked further yet, but regardless it occurs to me that the behaviour I’m seeing still suggests a problem with the browser. This is because I’m still not seeing the connection recover on closing the tab and opening a new tab - so different to your test code.

I’m busy with family for a week or so now, but if you want to look into it let me know and I’ll help you get a copy of plume going which allows you to create posts. You can probably figure it out yourself of course, but I’ll write the key bits down if you plan to look at it. One thing to do is to edit the config.json and set postsURI to a new path on a public ID that does not yet exist. This will be created when first run, when you Login and accept the Auth request. So for example:

"postsURI": "safe://gabrielstorage/posts" 

But don’t host your plume on the same public ID - it will work, but the debug console output won’t be as clear.

The rest is fairly straightforward but if anything is not clear ping me and I’ll write it down.