terascope / teraslice

Scalable data processing pipelines in JavaScript
https://terascope.github.io/teraslice/
Apache License 2.0
50 stars 13 forks source link

e2e autoload not properly deleting old assets #3465

Open sotojn opened 11 months ago

sotojn commented 11 months ago

I came across this issue when running e2e tests after we had just released new asset versions. Inside the autoload folder inside the e2e directory it still has all the old assets and the current assets inside it. This ends up causing a fatal error running tests locally.

All the code in charge of managing the assets in the autoload folder are inside e2e/test/download-assets.js

File: /teraslice/e2e/test/download-assets.js

133: async function downloadAssets() {
134:     await Promise.all(bundles.map(({ repo }) => downloadRelease(
135:         'terascope',
136:         repo,
137:         autoloadDir,
138:         filterRelease,
139:         filterAsset,
140:         leaveZipped,
141:         disableLogging
142:     )));
143: 
-> 144:     deleteOlderAssets();
145:     logAssets();
146: }

When calling downloadAssets(), it should download all the latest assets first, then check the autoload to see if there are older or duplicate assets, and then delete the duplicates/older assets.

As of right now if I do not manually clear out my autoload folder a fatal error happens when running a test. This is my autoload contents when the error occurs:

e2e/autoload
├── elasticsearch-v3.5.3-node-18-bundle.zip
├── elasticsearch-v3.5.4-node-18-bundle.zip
├── kafka-v3.5.1-node-18-bundle.zip
├── kafka-v3.5.2-node-18-bundle.zip
├── standard-v0.22.2-node-18-bundle.zip
└── standard-v0.22.3-node-18-bundle.zip

Then when running yarn test:elasticsearch7 inside the e2e directory I see this in my teraslice master logs container:

2023-11-14 10:35:41 <--- Last few GCs --->
2023-11-14 10:35:41 
2023-11-14 10:35:41 [62:0xffffa90872f0]     3001 ms: Scavenge 240.0 (251.7) -> 239.1 (252.0) MB, 1.2 / 0.0 ms  (average mu = 0.919, current mu = 0.945) allocation failure; 
2023-11-14 10:35:41 [62:0xffffa90872f0]     3329 ms: Mark-sweep (reduce) 266.2 (278.0) -> 255.4 (267.2) MB, 163.5 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 179 ms) (average mu = 0.742, current mu = 0.589) allo
2023-11-14 10:35:41 
2023-11-14 10:35:41 <--- JS stacktrace --->
2023-11-14 10:35:41 
2023-11-14 10:35:41 FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
2023-11-14 10:35:44 
2023-11-14 10:35:44 <--- Last few GCs --->
2023-11-14 10:35:44 
2023-11-14 10:35:44 [73:0xffff880e22f0]     2859 ms: Scavenge 240.2 (252.0) -> 239.3 (252.2) MB, 0.9 / 0.0 ms  (average mu = 0.899, current mu = 0.897) allocation failure; 
2023-11-14 10:35:44 [73:0xffff880e22f0]     3140 ms: Mark-sweep (reduce) 266.0 (278.2) -> 255.3 (266.5) MB, 139.1 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 146 ms) (average mu = 0.741, current mu = 0.579) allo
2023-11-14 10:35:44 
2023-11-14 10:35:44 <--- JS stacktrace --->
2023-11-14 10:35:44 
2023-11-14 10:35:44 FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
2023-11-14 10:35:47 
2023-11-14 10:35:47 <--- Last few GCs --->
2023-11-14 10:35:47 
2023-11-14 10:35:47 [84:0xffffa89122f0]     2889 ms: Scavenge 239.7 (249.7) -> 238.8 (254.2) MB, 1.0 / 0.0 ms  (average mu = 0.817, current mu = 0.774) allocation failure; 
godber commented 5 months ago

Didn't you or Peter fix this?