Cannot read property 'prototype' of undefined in dynamodb.js

[springmeyer]

Running into an odd error whereby AWS.DynamoDB is not defined right here.

This may be something messed up on the box experiencing the error, but figured it would be good to report it nevertheless. The situation is:

• node-pre-gyp, which uses aws-sdk, running on appveyor
• aws-sdk-2.0.0-rc.20.tgz is installed
• it looks like the error may be happening at require('aws-sdk)` but its hard to tell, might be anywhere inside https://github.com/mapbox/node-pre-gyp/blob/master/lib/publish.js.

Here is the log where it happens: https://ci.appveyor.com/project/springmeyer/node-mapnik/build/1.0.104#L1225

Any ideas what I might test to try to workaround?

[springmeyer]

I'm thinking this may be the byproduct of an s3 authentication user error.

[lsegal]

I'd be curious as to what you mean by an S3 authentication error. If you can provide code that reproduces it, that would be great-- I cannot seem to produce this issue with a regular npm install and a require('aws-sdk') call, which is where it should be raising the error from.

[lsegal]

I should add that I have seen this error before, but only when the aws-sdk-apis package is malfunctioning (which 3.0.2 should not be). Basically what (should) happen is this:

1. We define AWS.DynamoDB at lib/services.js#L10
2. We load the lib/services/dynamodb.js customization file on L14 in that same js file.

The services.js file is required when the SDK is loaded.

The problem here is likely that AWS.Service.defineService('dynamodb', '...'); is returning undefined, which causes AWS.DynamoDB.prototype to try to access prototype of undefined. Either that, or the "name" variable for DynamoDB is not actually "DynamoDB".

This should never happen, of course, since the DynamoDB model is correctly defined in aws-sdk-apis. It's possible that there's some Windows specific issue here, because we are reading a directory using the fs module, and that may be returning different things on Windows. That said, I just tested installing the SDK on a Windows machine and was able to load it.

[lsegal]

Actually -- it looks like this is a Windows specific issue, specifically with Node 0.11.x. I could not originally reproduce this because I was using the latest stable release of Node.js, 0.10.29.

It looks like there seems to be some kind of regression in Node.js 0.11.x on Windows. I would recommend opening an issue for this against the Node.js project.

Is there a reason you are using 0.11.x? The 0.11.x branch is not considered a stable release of Node, and you should only be using the stable releases for production code. The node.js homepage currently lists v0.10.29 as the latest release. I would recommend using that as a workaround.

[springmeyer]

Thanks for the feedback. I also cannot replicate locally on a windows VM, nor on OS X. The only place I'm seeing this on appeveyor.

Your comment just came in: Right, I'm using node v0.11.x for a very specific reason, which is that log output does not work on appveyor until node v0.11.x. (details on why at mapnik/node-mapnik#257 (comment)). I'm trying to debug what is likely a normal issue using aws-sdk to put data to s3 but because I can't see any errors with node v0.10.x I moved to testing just with node v0.11.x. So, its totally possible this error is also only happening for me on v0.11.x, but I can't know for sure its not occuring on v0.10.x due to the log output not showing up with earlier node.js versions.

[lsegal]

Looks like for some weird reason require('aws-sdk') fails but require('./node_modules/aws-sdk/lib/aws') manages to load fine. There must be something in the Node.js regression around loading of npm packages.

[lsegal]

So I did some digging through recent reported issues and managed to narrow down this issue to two related changes in Node.js 0.11.x that other users have reported as bugs:

• require() loads same module multiple times if case is different nodejs/node-v0.x-archive#6829
• path.join() changes casing of drive letter starting with 0.11.0 nodejs/node-v0.x-archive#7031

These two issues are related, but ultimately it's nodejs/node-v0.x-archive#7031 that actually causes the bug in loading the SDK. Basically, Node.js's require.cache lookup for require() calls is case sensitive, which means require("C:\foo") is different from require("c:\foo"). Because the SDK relies on modifying the object returned from a require, returning a different object breaks the way we load the SDK. This would not generally be a problem, except a related issue caused path.join() to start changing the case of the drive letter (see nodejs/node-v0.x-archive#7031) to lower-case. We use path.join() when loading custom service objects, which started to load "c:\...\core.js" instead of the previously loaded "C:\...\core.js". Because of the case-sensitivity of these two require() calls, we are effectively loading the SDK twice as two separate objects and two separate property sets, causing the "undefined property" exception.

My guess is the reason that require("aws-sdk") fails when require("./node_modules/aws-sdk/lib/aws") succeeds has to do with the first call loading the SDK with "C:\..." while the second probably starts off with "c:\...", lower-cased from the start.

Presumably this should fix itself once Node.js resolves these two related issues, but until then it is a trivial fix to work around this in the SDK. I will have a commit that fixes loading of the SDK in Windows using Node.js 0.11.x shortly.

[lsegal]

@springmeyer if you want to point your aws-sdk dependency at the above commit in our git repository, that should get you going to continue debugging your code against Appveyor. I know that this is not your root problem, so feel free to open any other issues or ask questions if it turns out the SDK is doing something weird with your node-pre-gyp code that causes your issue.

Hope that helps!

[springmeyer]

Thanks! Just had a chance to try latest master and the original error is gone with node v0.11.x. I'm now seeing this error but that may be something on my end.

[lsegal]

It's certainly possible that there are other 0.11.x related issues. I know that we have had issues testing against various 0.11.x versions with the SDK, especially when it comes to passing streams through to S3. It's unfortunate that you can't get logs from 0.10.x to see the original error.

[springmeyer]

Yes, I'm going to hold on using v0.11.x for now. In the meantime I've figured out the cause for things not working on v0.10.x (mistake in s3 credentials) so I'm no longer forced to use v0.11.x. So, thanks!

Once v0.12.x is out I'll be sure to help test aws-sdk again.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.