Processing of coverage results failed due to out of memory

We are using coveralls GH action for sending coverage.info file to Coveralls service (see settings in workflow). coverage.info file has been prepared using lcov (see command-line).

Using lcov file: ./coverage.info
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

 1: 0xa1a640 node::Abort() [/opt/actions-runner/externals/node12/bin/node]
<--- Last few GCs --->

[3559340:0x436a000]    34083 ms: Scavenge 2035.3 (2043.7) -> 2035.7 (2045.0) MB, 16.3 / 0.0 ms  (average mu = 0.286, current mu = 0.269) allocation failure 
[3559340:0x436a000]    34104 ms: Scavenge 2036.6 (2045.0) -> 2036.2 (2058.5) MB, 19.7 / 0.0 ms  (average mu = 0.286, current mu = 0.269) allocation failure 

 2: 0xa1aa4c node::OnFatalError(char const*, char const*) [/opt/actions-runner/externals/node12/bin/node]

 3: 0xb9a62e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/opt/actions-runner/externals/node12/bin/node]
 4: 0xb9a9a9 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/opt/actions-runner/externals/node12/bin/node]
<--- JS stacktrace --->
 5: 0xd57c25  [/opt/actions-runner/externals/node12/bin/node]

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x140dc19]
Security context: 0x0ac539b808d1 <JSObject>
    1: encode(aka encode) [0x2542af49d2d9] [/opt/actions-runner/_work/_actions/coverallsapp/github-action/v1.1.2/node_modules/qs/lib/utils.js:~118] [pc=0x3c36c357d22](this=0x07b6cc3404b1 <undefined>,0x042449f00151 <Very long string[60387932]>)
    2: stringify(aka stringify) [0x2542af49d091] [/opt/actions-runner/_work/_actions/coverallsapp/github-action/v1.1.2/no...

 6: 0xd582b6 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/opt/actions-runner/externals/node12/bin/node]
 7: 0xd64b75 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/opt/actions-runner/externals/node12/bin/node]
 8: 0xd65a25 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/opt/actions-runner/externals/node12/bin/node]
 9: 0xd670cf v8::internal::Heap::HandleGCRequest() [/opt/actions-runner/externals/node12/bin/node]
10: 0xd15b35 v8::internal::StackGuard::HandleInterrupts() [/opt/actions-runner/externals/node12/bin/node]
11: 0x1071[17](https://github.com/tarantool/tarantool/actions/runs/3226116658/jobs/5279742684#step:7:18)6 v8::internal::Runtime_StackGuard(int, unsigned long*, v8::internal::Isolate*) [/opt/actions-runner/externals/node12/bin/node]
12: 0x140dc[19](https://github.com/tarantool/tarantool/actions/runs/3226116658/jobs/5279742684#step:7:20)  [/opt/actions-runner/externals/node12/bin/node]

Why processing took so much memory (~2 Gb)? How to avoid error due to OOM?

Full log - https://github.com/tarantool/tarantool/actions/runs/3226116658/jobs/5279742684
Version: coverallsapp/github-action@v1.1.2

Sample of file, that triggers OOM - coverage.zip

Start with the coverallsapp/github-action@v1.1.2 processing path shown in the log, especially qs/lib/utils.js, and reproduce the failure using the attached coverage.zip. Compare the action's handling of the large lcov input with the workflow and .test.mk lines 122-133; done means identifying the memory cause and documenting or implementing a way to process this coverage without the OOM failure.