Plugin development error loop without useful feedback #48883
Description
Kibana version:
Current master
Elasticsearch version:
v8.0.0
Steps to reproduce:
This is one example of how to get the out-of-memory error loop going.
- Change the value of
devTools(here in searchprofiler) to a non-existent file. - Run
yarn start - Wait for optimizer to kick in
Alternatively: if a non-existent module is imported into a ts file in combination with // @ts-ignore the same result is achieved.
Why would you ever do this? Primary reasons I can think of:
- NP migration
- Using "legacy"
jsin newts - Building a new plugin
Expected behavior:
I would expect better feedback about the root cause. In the case described above it is the file that is not resolving correctly. Getting into this error state is very unhelpful.
Currently, for example, new platform migrations or instances of using js modules in ts modules can be very tricksy to debug.
Logs in console:
Looks like the cause is src/legacy/server/logging/apply_filters_to_keys.js: 27, but this is obviously triggered by something else (see steps above)
Sample of the repeating OOM exception:
...
<--- Last few GCs --->
[2754:0x108000000] 32454 ms: Mark-sweep 1042.7 (1283.5) -> 1042.3 (1239.0) MB, 331.2 / 0.0 ms (average mu = 0.587, current mu = 0.000) last resort GC in old space requested
[2754:0x108000000] 32783 ms: Mark-sweep 1042.3 (1239.0) -> 1042.3 (1224.0) MB, 328.9 / 0.0 ms (average mu = 0.410, current mu = 0.000) last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x31754a99e6e1 <JSObject>
0: builtin exit frame: parse(this=0x31754a991a19 <Object map = 0x3175208042a9>,0x31751136b4a9 <Very long string[131992282]>,0x31754a991a19 <Object map = 0x3175208042a9>)
1: toPojo(aka toPojo) [0x3175f074e631] [/kibana/src/legacy/server/logging/apply_filters_to_keys.js:27] [bytecode=0x31756422b091 offset=30](this=0x3175574026f1 <undefined>,obj=0x317532d5..
...