#7 · closed · 8 comments
### What happened? Loading a file on https://platform.thatopen.com/app and i receive the error below. ### Version latest ### What browsers are you seeing the problem on? Microsoft Edge ### Relevant log output ```shell Uncaught (in promise) RangeError: Set maximum size exceeded at Set.add (<anonymous>) at aG.getAllGeometriesIDs (9249.a39bde93b4db5cf6.js:6:393264) at async aG.export (9249.a39bde93b4db5cf6.js:6:392019) ``` ### Anything else? Model has been sent to [email protected]
@agviegas email sent. Thanks!
File privately shared [here](https://drive.google.com/file/d/1fUfJ2eTPoqAkIsj-oB4PLQaoML1CrW14/view?usp=sharing).
@agviegas file does parse and generate successfully in web-ifc - so I think the bug is in components - so moving it
I have encountered this issue too and did some investigation: * The issue happens when loading a file, particularly in chrome-based browsers which have a 16 million elements Set limit * this caused the `export` function to fail and never trigger `onPropertiesSerialized` * so the parent Promise in data-converter.js > `getModelProperties` never gets resolved or at the very least rejected It is still a relevant issue in the latest 1.3.2 @HoyosJuan Can I just put a try catch around the `export` code in IfcJsonExporter and do an `await this.onPropertiesSerialized.trigger({})`?
Probably a cause for this issue is that we are loading everything in memory at the same time, which is not very scalable. Hopefully with the BIM tiles approach, which is around the corner, this will be solved.
> Probably a cause for this issue is that we are loading everything in memory at the same time, which is not very scalable. Hopefully with the BIM tiles approach, which is around the corner, this will be solved. Chunking the geometry ids across multiple <16M sets would indeed fix this. I'm excited to see what BIM tiles can do! Until then, a workaround like the try catch I mentioned would be very useful to be able to notify the user that properties couldn't be loaded instead of waiting for them forever.
Yes @davidgtl, I see why not adding the try/catch statement as a workaround for now. Will let you know when it's done.
This should be solved in the latest version. Let us know otherwise!