Cannot read property 'user' of undefined

[semateos]

    at Object.run (methods.js:35)
    at MethodInvocation.newMethodOptions.run (wireMethods.js:139)
    at ValidatedActionMethod._execute (validated-method.js:94)
    at MethodInvocation.setTaskDone (validated-method.js:57)
    at DDP._CurrentMethodInvocation.withValue (livedata_connection.js:664)
    at Meteor.EnvironmentVariable.EVp.withValue (meteor.js?hash=33066830ab46d87e2b249d2780805545e40ce9ba:1196)
    at Connection.apply (livedata_connection.js:653)
    at ValidatedActionMethod.call (validated-method.js:70)
    at Promise (callpromise-mixin.js:4)
    at new Promise (<anonymous>)
    at ValidatedActionMethod.callPromise (callpromise-mixin.js:3)
    at ValidatedActionMethod.js:24```

[semateos]

Looks like it's missing the user from auth object here:

meteor-redux/imports/api/tasks/methods.js

Line 35 in dfd5bce

const userId = auth.user._id;

[wswoodruff]

Is the title of this the error you're getting? If so, then we're missing the auth prop. It gets set on this line, and only gets set if Meteor.isServer.

Could you poke around in here and see if the line is even getting run? Did they remove Meteor.isServer or something I wonder?

meteor-redux/imports/lib/wireMethods.js

Line 136 in 94ecd4b

argsClone.auth = { user: foundUser };

[joerou]

This is because the user is only added to the auth object if meteor.isServer. The problem with that is that validated methods run on both the client and the server (for optimistic ui). So it fails on the client because user doesn't exist, then works fine on the server and updates the ui to the correct state. Which is why the function appears to work, but still throws that error to the client console.

My guess is that you checked the login token instead of checking this.userId in the method because apollo instead of using the meteor way. So I would assume the best way to fix this is to add the currently logged in user above this and then only override it with the server variable if its being run on the server.

[wswoodruff]

Hey that sounds about right — thanks for those thoughts!!

I wonder if any extra optimistic UI code was added in the update path we just upgraded to. (I think we went from Meteor 1.6 — 1.8)

[semateos]

@joerou can you take a shot at fixing that?

It seems to me (although memory is untrustworthy) that the optimistic UI is not working as it was in the previous version. My recollection was that it had better offline behavior. Could be related to this failure on the client side.

[joerou]

Yep, I'll take care of it.

[joerou]

I made a fix for this, see the latest PR.

I just used the Meteor default for loggedin user instead of checking the hash token. Then I split out the ownership logic so a different error could be pushed to the client if they were loggedin but not the owner.

[semateos]

@wswoodruff how does that sound? Can you give it a quick review? Thanks!

[joerou]

I was doing some experimenting this week and the solution works, except when calling from the graphiql interface, it seems this.userId is defined, but always returns null. It seems this should be set via the apollo ddp package but apparently something is getting lost. When looking into that I found there is a new way of creating the apollo client and the apollo server in the docs, maybe this is a better route? I started looking into and will keep going this week.

In the meantime I have set the old method to run on the server and set the fix to run on the client, so the auth.user object is always set and that will work for now.

[semateos]

OK