safeNfs.create() - Error: First argument must be a string, Buffer, ArrayBuffer, Array

Peruse: 0.3.4 (custom build) and SAFE Browser 0.7.0 (MS build) give me a strange error with safeNfs.create(). This is using code which worked before the latest API changes (though much modified I don’t see my changes as likely the problem, but you know, it is me :wink:).

Uncaught (in promise) Error: First argument must be a string, Buffer, ArrayBuffer, Array, or array-like object.
    at fromObject (buffer.js:274:9)
    at Function.Buffer.from (buffer.js:106:10)
    at module.exports.api.file_write.h.Promisified (/home/mrh/src/safe/peruse/release/linux-unpacked/resources/app.asar/node_modules/@maidsafe/safe-node-app/src/native/_nfs.js:103:64)
    at Promise (/home/mrh/src/safe/peruse/release/linux-unpacked/resources/app.asar/node_modules/@maidsafe/safe-node-app/src/native/_base.js:187:32)
    at Promise (<anonymous>)
    at Object.varArgs [as file_write] (/home/mrh/src/safe/peruse/release/linux-unpacked/resources/app.asar/node_modules/@maidsafe/safe-node-app/src/native/_base.js:183:16)
    at File.write (/home/mrh/src/safe/peruse/release/linux-unpacked/resources/app.asar/node_modules/@maidsafe/safe-node-app/src/api/emulations/nfs.js:127:16)
    at open.then (/home/mrh/src/safe/peruse/release/linux-unpacked/resources/app.asar/node_modules/@maidsafe/safe-node-app/src/api/emulations/nfs.js:188:28)
    at <anonymous>

Here’s the code on github (not everything is pushed ATM so let me know if needed - I also have a live version at safe://solidpoc5, click Menu > Login, Menu > New Post, fill out the post form and “Publish”).

https://github.com/theWebalyst/solid-safenetwork/blob/wip/src/safenetwork-solid.js#L1047

2 Likes

I’m receiving the same error at the moment because each browser isn’t allowing me to use fileReader.readAsArrayBuffer... and so my script ends up trying to window.safeNfs.create... with an undefined file content argument.

When you log your body argument, what is the value?

Really what this is highlighting is our need to handle these errors and give much more useful messages to the user.

2 Likes

The body looks fine (in this case it contains text, or rather RDF turtle - a bit like JSON) . I think it’s a string, and used to work with this same code, so maybe the API or something underneath has changed?

EDIT: I’m wondering if it’s no longer OK to pass a string, but I don’t know where to look for API changes. The DOM API docs says it should be Buffer but I can’t find an example that shows what to do with a string.

No, you’re still fine passing a string.
I just tested that and it works.
When I get a chance I get your repo running locally to see what I can on my end.

1 Like

This makes me think its the container handle so I’ll look into that when I get back to it.
__

I haven’t been able to run locally so I’m developing live. I’ve invited you to the PM thread related to that:

https://forum.safedev.org/t/https-localhost/1273/17?u=happybeing

Looks like I’m getting boxed in here!

I need to push the latest solid-plume code if you want to try this - ping me beforehand on Riot.im and I’ll fire the laptop up.

Update: @hunterlester I’ve looked at my handles (ahem) and did find some bugs but not affecting this. I’ve pushed all changes to github, but note you would need to build my solid-safenetwork.js (npm module), then my forked rdflib.js (npm run build:browser) and copy the dists to my solid-plume fork (those links all go to the relevant branches) if you want to get into that. That’s cos I use symlinks from my solid-plume to solid-safenetwork/dist/solid-safenetwork.js and also to my built rdflib.min.js.

I’m not sure how to debug this further. It could be my code, but other things are fine and everything points to my handles being ok at the point of safeNfs.create() because I call that shortly after listing the entries of _public (you’ll see this in the console output if you try it live - see the OP).

I’m still using peruse --ignore-certificate-errors (custom built so it allows https although I’m not using http/https in the live version ATM). I did also try with SAFE BRowser 0.7.0 yesterday and got the same result.

So it is pointing towards a bug in safe_app_nodejs, but hard to say and I don’t know how to look into that yet. Also, probably best I continue working on the Solid libs (I can be designing the next phase in the meantime). So if you or one of the MaidSafe team can help that would help me progress.

I may be very close to the first level PoC :slight_smile:. It has lots of limitations, so a bit of a leap to the next level, but I think that may be very nice, and lead on to a library not just for LDP as a SAFE service, but for easily adding other services: backends like RemoteStorage as a SAFE service, and even a file sharing service which I’ve been wondering how to do forever it seems :slight_smile:. For third parties this just might all work by including one npm module (safe-services) and ensuring the app is using standard fetch().

Update 2: Hunter, your suggestion for mock using an http server works (good enough for now), so I can confirm the above bug is still present running with mock. Any tips on how to debug the browser error. Can’t see much in the sources pane yet.

3 Likes

I’m up and running for now. I need to pause for now and resume either later today or tomorrow.

Next I’d like to get logs setup to understand what’s running and in what order.

I’d like to find out why the app appears to connect successfully but is then logging a malformed app info error.
I also want to understand why the web view is crashing, see the black screen in the background.

I usually reproduce that crash when I attempt to use fileReader methods to read a file buffer, however, it seems to be a different case here.

1 Like

Great @hunterlester (see my Update 2 above).

appears to connect successfully but is then logging a malformed app info error.

I get this too but don’t think it is a problem (its a bug I fixed earlier, not sure why it is back! but it is probably trying to auth twice - first fails - second succeeds, so not the real issue here, but I will look into it). Update: I was getting this earlier and did make some changes which may have stopped it, but it is now back and I don’t understand why I get this. Earlier I was sometimes calling before being logged in to SAFE (live) but I’m logged into SAFE (mock) and its happening. So this is in fact unexplained, though not necessarily related to the OP error.

I do NOT get the tab crash though. I have my web app running ok and can interact with it to reproduce the bug I describe in the OP. I’m just not sure yet how to use peruse / yarn dev to delve into the safeNfs.create() error. I looked through the browser sources pane but can’t see much to do with SAFE yet. Any tips on that appreciated. No worries if you don’t have time.

Update: Your tab crash might be that you’re using SAFE Browser (yes?). I’m using Peruse. There’s a bug in electron (using SB built for mock) and one of the reasons for the switch to Peruse is to avoid that crash!

1 Like

@hunterlester @joshuef I’m racking up further issues trying to test some new code I’ve written and so hoping there might be some news on the above. At the moment I’m using Peruse-mock and seeing the Malformed AppInfo error (as in Hunter’s screenshot above), although I am also seeing successful Auth. I’m calling auth twice and the second succeeds.

My new code then proceeds to ask for further authorisation using the sample from the API docs with a slight mod to check for reject():

     window.safeApp.authoriseContainer(
       this._safeApp, // the app handle obtained when invoking `initialise`
       { _publicNames: ['Update'] } // request to update into `_publicNames` container
     ).then((authUri) => {
        safeLog('App was authorised and auth URI received: ', authUri);
     }, (err) => {safeLog('Error: ', err)});

But although the Peruse debug console shows [21:01:50.509] on.....onContainerReq Persue doesn’t show an Auth popup and the promise never resolves or rejects.

I’m slightly worried in case its how I’m building my nodejs module rather than Peruse or anything else in the SAFE API, but not sure how to work out what is happening given the mounting errors.

So I’m hoping you guys can look deeper into the issue in the OP and perhaps the Malformed AppInfo errors to see whether its Maidsafe code or mine? I’ll be taking time out middle of Tuesday but around later.

Thanks :slight_smile:

2 Likes

Morning,

Just playing catch up now, @happybeing. But it could be there’s a bug in the onContainerReq portion of the code in Peruse.

I’ll get to pulling the branches etc and hopefully can get onto running this later today. Will let you know!

1 Like

Welcome back Josh. I hope you had a great time :slight_smile:

I realise you will have lots to catch up on, so not expecting miracles, although… you know, maybe :slight_smile:

And I’m busy today anyway, so not waiting on you. One thing I am confused about is that running Peruse with yarn dev I couldn’t see the Maidsafe sources in the peruse debug console. I looked through everything there! So I wasn’t able to to debug peruse itself, or see what might be causing the API errors. Again no hurry, but I’m curious about how to do that.

In the debug console of electron/peruse you mean?

What are you running in? You should have a .log file generated in the dev directory which should have a fuller log output (using electron-log, which is used via the calls to logger.info(...) which you can see about the place)

Yes, I can’t find the Maidsafe sources (for peruse calls to API or anything really) in the peruse debugger (not the Web page debugger).

I haven’t checked the logs, will look later, but I was expecting to be able to inspect code, variables, and set breakpoints inside peruse itself.

This should be doable.

You can log to both the console and the electron-console (of the renderer process), via logger.info (assuming you’re imported logger).

I think, if you’re trying to get to the JS/peruse code in the inspector, you might have a harder time as it’s compiled. You should be able to add logs etc to the code itself though and see your outputs there. (does that make sense?)

1 Like

Ah, ok, so I’m not missing a trick then. Thank you :slight_smile:

1 Like

Hi @hunterlester is this still on your list? I’m still productive atm, working on features for a SAFE web services API that will I hope enable a proper Solid+SAFE integration, but may have that done soon and then this will be the blocker.

@joshuef would it help if I created an issue for this? I’m guessing that we at least want a better error message here - I can leave the code up live on the link in the OP.

If you guys are just on higher priority stuff, no worries. I can dig further into it once the services API is done, and I also have a few things in the failing code I can refactor and who knows, that might solve it anyway.

1 Like

Thanks for the bump. Been bogged down.
But I’d really like to dedicate a minimum amount of time everyday to help with any issues for this project.

The container request issue is solved with yesterday’s commit: https://github.com/joshuef/peruse/commit/4cadb48fb34b81e0f628530bb7ea206ae31fa024

Make a pull and see how that works for you.

Are you not able to see your files in the source tab of dev tools?
Or are you not able to see logs that you’ve placed in your code?

Thanks Hunter - no probs if you don’t have time for this yet!

I already have that and confirm it works.

Josh has explained about debugging peruse (ie maidsafe sources not available, so must use logging) but I haven’t tried that yet. I’m still working on the rest of my code and keeping the OP issue until last - in case you guys can clear it up or it just goes away during refactoring.

Many fixes coming out tomorrow with Peruse.
My plan is to then fire up your application again to see what’s been sorted by the browser updates and what’s left over to solve.

6 Likes

Thanks for the update Hunter. I look forward to trying the new browser :slight_smile:

I’ve been able to get lots of stuff done in the mean time - my services API is almost complete and I’m about to create the first a service implementation which will bring me back to the safeNfs.create() code, though I will refactor it in the process. So your timing is good - either it will magically start working or I’ll be needing to crack this one before long - wild guess: first half of next week.

5 Likes