TES-4800 allow exposing waitForFlush capability

[benjamingr]

Hey,

As discussed on email.

• I added a test to help you accept the code. I tried running the linter but it did not pass on master. I made sure not to introduce any new lint issues.
• I noticed dist is committed so I ran a build - I would recommend removing it from the repo as it is derived from the source.

Cheers and love,
Benji and Moshe

[oded-dd]

Codecov Report

Merging #15 into master will decrease coverage by 17.98%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master      #15       +/-   ##
===========================================
- Coverage   93.77%   75.79%   -17.99%     
===========================================
  Files          12       12               
  Lines         241      252       +11     
===========================================
- Hits          226      191       -35     
- Misses         15       61       +46     

Impacted Files	Coverage Δ
dist/entities/LoggerConfig.js	33.33% <0.00%> (-66.67%)	⬇️
dist/entities/bulk.js	40.00% <0.00%> (-60.00%)	⬇️
dist/http.service.js	42.10% <0.00%> (-57.90%)	⬇️
dist/entities/buffer.action.js	60.00% <0.00%> (-40.00%)	⬇️
dist/debug.logger.js	63.63% <0.00%> (-36.37%)	⬇️
dist/entities/logs.buffer.js	71.42% <0.00%> (-28.58%)	⬇️
dist/helpers/rx.helper.js	85.71% <0.00%> (-14.29%)	⬇️
dist/entities/log.js	87.87% <0.00%> (-12.13%)	⬇️
dist/helpers/ip.helper.js	68.42% <0.00%> (-10.53%)	⬇️
dist/logger.manager.js	82.08% <0.00%> (-1.84%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5eead77...f0f344e. Read the comment docs.

[codecov-io]

Codecov Report

Merging #15 into master will increase coverage by 0.66%.
The diff coverage is 90.9%.

@@            Coverage Diff             @@
##           master      #15      +/-   ##
==========================================
+ Coverage   93.77%   94.44%   +0.66%     
==========================================
  Files          12       12              
  Lines         241      252      +11     
==========================================
+ Hits          226      238      +12     
+ Misses         15       14       -1

Impacted Files	Coverage Δ
dist/logger.manager.js	89.55% <90.9%> (+5.62%)	⬆️
dist/http.service.js	94.73% <0%> (-5.27%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5eead77...2c2c9ba. Read the comment docs.

[benjamingr]

This PR addresses an issue where logs are dropped if the Node server is shut-down by exposing an API letting coralogix-logger wait for logs to be sent from the backend.

The original issue is very easy to reproduce. You can call:

tester.addDemoLine();
process.exit();

In tester.ts to see that it's not sent to the backend :]

[benjamingr]

Hey, this was supposed to be merged a month ago. You said "3-4" weeks - any update?

[benjamingr]

Ping? Another month has passed

[benjamingr]

Ok, @amnons77 I feel like your company is friends with my company so the charitable thing would be to give out free advice from a Node core team member who also maintains several open source libraries and breaks stuff myself all the time.

For what it's worth, the way this logger is written isn't how you're supposed to write loggers for Node.js.

Even if you remove all the deprecated and old APIs the code uses (like request and rxjs) and how much it actually needs those dependencies for (it doesn't, it can be significantly shorter without them) - there are fundamental issues namely:

• A logger is fundamentally infrastructure, I shouldn't feel it in my code.
• A logger should have few or zero dependencies.
• Unless logging can be as fast and reliable as writing to a stream, a logger should read from stdout and write to an endpoint.
• Things like "logs get to their target" is not a luxury feature. Waiting for an interval before terminating is not an acceptable solution to that. Logs are critical for root cause analysis.
• I'm not even talking about expecting the logger to understand my code. I assume the Java version understands the function and method name it's coming from (I see fields for that). Other loggers understand source maps and basic code structure. Since coralogix runs on elasticsearch, you could just "steal" the code from elastic if you need to add support.

There are also some quick wins you can do, probably use a reasonably fast library for writing stuff and a reasonably fast JSON library. Those are dependencies that would actually be justified IMO.

If you start with pino/pino-http that would probably be a good starting point :]