Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeError: Cannot read property 'length' of undefined #18

Closed
TheDeveloper opened this issue Jul 25, 2014 · 12 comments
Closed

TypeError: Cannot read property 'length' of undefined #18

TheDeveloper opened this issue Jul 25, 2014 · 12 comments

Comments

@TheDeveloper
Copy link

TypeError: Cannot read property 'length' of undefined
    at Function.self (/home/app/node_modules/memoizee/ext/async.js:88:67)

Seems similar to #13 except I'm not sure of what exact scenario triggers this.

In ext/async.js, It seems that cb is assumed to either be a function or an Array of functions from the waiting[id] property. However, somehow, occasionally waiting[id] seems to be undefined when this code runs causing cb to also be undefined, which throws the error when cb.length is called when the 'setasync' method is emitted.

Is there possibly some race condition going on here where once callback clears the waiting queue before another unexpectedly tries to run? Can you think of any possible reasons why cb could be undefined?

Observed on v0.3.5 and previous versions.

@medikoo
Copy link
Owner

medikoo commented Jul 25, 2014

@TheDeveloper are you using some custom normalizer? How memoization of function is configured?

@TheDeveloper
Copy link
Author

Sorry, I should have mentioned. These are the options:

{
    async: true,
    primitive: true,
    maxAge: self.conf.ttl.memory,
    resolvers: [String],
    length: 1
  }

I only require a single string argument, the 'key'.

@medikoo
Copy link
Owner

medikoo commented Jul 25, 2014

And it's when using latest version?

@TheDeveloper
Copy link
Author

Yes I got this today in an app running v0.3.5

@gabmontes
Copy link

While doing a deeper analysis of my code that ends up in #13 once in a while, I also found that it fails in the only memoized fn with 'primitive' set to 'true' as my original fn receives an array.

Anyway, as @TheDeveloper says, there should be some race condition out there, happening even in the last version.

@medikoo
Copy link
Owner

medikoo commented Jul 26, 2014

It'll be great to have some reproducible test case, but I'll try to work this out, having above info.

@TheDeveloper
Copy link
Author

Agreed but due to their stochastic nature, it is very difficult to create a reproducible test case for a race condition.

Side thought - could this happen if the callback to the async operation is called more than once?

@TheDeveloper
Copy link
Author

Thanks for looking into this, I'll test the changes!

@medikoo
Copy link
Owner

medikoo commented Jul 28, 2014

After analyzing the code, I was able to reproduce it with working test case. It was related to race condition issue that could happen after reapplying function with previously used arguments after clear/delete call.

Indeed fix applied at #13 addressed issue just partially, and didn't took into account possibility of repeated call with same id in case of primitive handling.

Published with v0.3.6

@gabmontes
Copy link

@medikoo thanks for addressing this! Will also test the new version.

@TheDeveloper thanks for your insights too!

@TheDeveloper
Copy link
Author

Update: I am no longer seeing the exception in our logs 😄

@medikoo
Copy link
Owner

medikoo commented Jul 30, 2014

Great to hear that, I'm pretty sure applied fix is bulletproof :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants