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

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

@happybeing Back at it.

Okay, so the error that I’m seeing seems to be about an attempt to get a container that the Plume doesn’t ask permission for:

listContainer is called on _publicNames but that wasn’t a container asked for during safeApp.authorise, given this default permissions: https://github.com/theWebalyst/solid-plume/blob/safenetwork-poc/app/app.js#L23

UPDATE:
I added _publicNames request and that resolves that error.
I am however running Plume in localhost so I get

[safe-tmp] failFetch([object Object],Request to safe://solidpoc05/ldp/solid-plume01/posts/ timed out,timeout)
fetcher.js:872 @@ Recording failure for <safe://solidpoc05/ldp/solid-plume01/posts/>: timeout

I’ll have to upload or change the requested URI so that posts may be fetched.

I’m still hunting down why this error is occurring:

safe:solid SAFEApp SafeNetwork Initialise Failed: Error: 
    Malformed appInfo.
    Make sure you conform to proper format and that id, name, and vendor are defined:
    {
      id: 'net.maidsafe.example.id',
      name: 'Name of App',
      vendor: 'MaidSafe Ltd.',
      scope: null
    } +17ms

I’ve got logs in all the right places but I can’t sniff it out yet, however I don’t think it’s affecting your app.

Thanks Hunter, I don’t think either of those are a concern for me. The containers I already have listing fine and the “Malformed appInfo” error is not a concern for me - I think it is just Peruse not handling a request for Auth properly when the user is not logged into an account.

It looks like you’ve pulled some other code there, although maybe not my latest code as that lists containers w/o problems. I don’t recall what was in the code in the OP, which causes the error in the title, but what stumped me was the safeNfs.create() error in the OP title, as the params looked fine in the browser debugger.

I have not yet tried it with the latest Peruse tho, so first step would be to repeat this test, as the live code (see below) hasn’t been changed. I shall download latest Peruse and report back…

UPDATE: the safeNfs.create() error of the OP is still present in Peruse 0.4.1. <<- this is the only thing I need help with at the moment. I am going to start re-factoring that code though, so once I’ve done that I’ll be able to test if this problem remains. In the mean time, it seems that the issue might be either an obscure bug, or more likely just not a very helpful error message.

Oh I see now:
I placed a log here just above this line: https://github.com/theWebalyst/solid-safenetwork/blob/wip/src/safenetwork-solid.js#L1032
console.log('createFile arguments: ', arguments);

The second argument of _createFile, body, is a request object and is directly fed to safeNfs.create:
return window.safeNfs.create(self._nfsRoot, body) but it appears that body.body should be provided instead as the contents of the file to be created on the network.

UPDATE: I just change it to body.body and console no longer logs safeNfs.create error.

Unless you do want the fileContents to be the request object, then you can just stringify it.

1 Like

Thanks Hunter, you know I thought I’d tried that but I guess not. I tried a few things along those lines but obviously not that :blush:

I shall have a go myself and confirm all’s well. Thank you again :smile:

1 Like

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