Error: Assertion Failed: index must be within bounds

[josiahbryan]

Error: Assertion Failed: index must be within bounds
    at new EmberError (http://localhost:4200/assets/vendor.js:37531:25)
    at Object.assert (http://localhost:4200/assets/vendor.js:37773:15)
    at SkipList.set (http://localhost:4200/assets/vendor.js:235879:69)
    at DynamicRadar._measure (http://localhost:4200/assets/vendor.js:236175:34)
    at DynamicRadar._shouldScheduleRerender (http://localhost:4200/assets/vendor.js:236134:12)
    at http://localhost:4200/assets/vendor.js:236024:22
    at Array.execJob (http://localhost:4200/assets/vendor.js:182126:9)
    at Scheduler.flush (http://localhost:4200/assets/vendor.js:182196:17)
    at http://localhost:4200/assets/vendor.js:182180:17"

The vendor.js mentioned in stacktrace above is attached here: vendor.js.gz

I've worked around it by patching skip-list.js to remove the offending assert() and instead do:

    if(!(index >= 0 && index < this.values.length))
	return delta;

(Note: The stack trace and vendor.js file above were both taken BEFORE I patched skip-list.js)

However, since I don't understand the internals of the project, I have NO idea if that will even solve the problem - all I know is that my client stops crashing.

I'd really like to get the underlying issue fixed - but I don't know what it is. All I know is sometimes when I scroll too fast, it throws that assertion.

The only thing I can think that would be relevant about my use case is that it's a newsfeed scenario with <img>s in it which load after being added to the DOM. (E.g. the item scrolls into view before the remote image is loaded sometimes, then the image gets loaded, which causes the widget to resize obviously)

Thoughts on how to fix or do you need more info...?

[pzuraq]

This is fundamentally caused by some inconsistency between reality (the number of items actually rendered) and our backing datastore. Removing the assertion may prevent failure, but won’t fix the underlying problem.

The SkipList is a datastructure that stores the measured heights of all of the items in the collection. So, when you attempt to set an index which does not exist (outside of the max length of the list), it means either we’ve updated the number of items, but we haven’t updated the SkipList, or we’re doung our math wrong and attempting to update the wrong index. Both of these possibilities are very bad, which is why the assertion is there.

Diagnosing the root cause here is tricky, in part because the internals are fairly spaghetti at this point. I’m planning on spending some time refactoring the Radar classes in the near future, need to finish up the work I’n doing for Ember Table first.

[josiahbryan]

I totally understand the torture of spaghetti internals - dealt with that in my own projects. No worries.

In the short term, I'm content to avoid failure - the last thing I want is the UI to suddenly become unresponsive because the assert is thrown. Ember just crashes entirely when an assert hits, so it seems, so that's the main issue to me - preventing total meltdown of the UI.

As far as WHY the assert is thrown - I totally understand, internally in your project, it's guarding against a bad thing. So far, everything continues to function properly /for me/ - however, I get that it may not with that assert not being guarded against.

Is there anything I can do to assist in root cause diagnosis or any more info needed? Or best situation just to wait for your refactor to land and update my project to use the "new" version and see if it happens again?

[pzuraq]

Ember crashes when asserts are thrown, but asserts are completely stripped out of production builds (along with lots of other code!) so your users shouldn’t experience any issues if you don’t experience them without the assert. They’re there for catching failures early, kind of like inline unit tests 😄

Definitely could use help figuring out what’s wrong. I’d start by putting a breakpoint at that assert and looking at what index its asking for. It should be less than the size of the collection you are passing to VC, if it isn’t then we’re asking for the wrong index for some reason. If it is, check the length of the skiplist, it’s probably the wrong size (it’s length should be the same as your collection)

[josiahbryan]

No problem - good to know re: stripping.

Re: breakpoint - just did that, and it looks like it's the former condition - the index is NOT less than the end of the skip list. (At the breakpoint, index = 9 and this.values.length = 9).

(I added a console.error statement in there just to show something before breaking, that's what you see in the screenshot right before the breakpoint line.)

[rafael-tanaka]

Well, I'm facing the same in our client and they decided to stop using this add-on due to the lack of support and documentation. Also the demos seems to be broken like this one https://html-next.github.io/vertical-collection/#/examples/dbmon.