@tus/server leaks memory

[mitjap]

Initial checklist

• I understand this is a bug report and questions should be posted in the Community Forum
• I searched issues and couldn’t find anything (or linked relevant results below)

Steps to reproduce

I get huge memory leaks with latest version of @tus/server with @tus/s3-store while using node 20.3.

Function AbortSignal.any has a memory leak in early versions. It was added in v20.3.0.
The bug is in node itself but has severe effects on users of @tus/server. This issues is discussed here.

Fix is available in v23.1.0 and v22.12.0.

What can we do?

• We can bump required node version to v22.12.0 (this would still leave users of v23.0.0 susceptible to this issue).
• We can bump required node version to v23.1.0 (it is not a LTS version)
• Stop using AbortSignal.any and with it avoiding all problems

Any thought on this?

Expected behavior

No memory leak :)

Actual behavior

Server crash even when handling a single 25GB file.

I get this output from node when it crashes.

<--- Last few GCs --->

[1726575:0x7457640]   746885 ms: Scavenge 2024.5 (2069.8) -> 2022.5 (2071.1) MB, 7.48 / 0.00 ms  (average mu = 0.195, current mu = 0.172) task; 
[1726575:0x7457640]   746903 ms: Scavenge 2025.7 (2071.1) -> 2024.2 (2073.8) MB, 9.11 / 0.00 ms  (average mu = 0.195, current mu = 0.172) task; 
[1726575:0x7457640]   746922 ms: Scavenge 2028.5 (2073.8) -> 2026.7 (2091.8) MB, 9.21 / 0.00 ms  (average mu = 0.195, current mu = 0.172) task; 


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xc8e4a0 node::Abort() [node]
 2: 0xb6b8f3  [node]
 3: 0xeacb10 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 4: 0xeacdf7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 5: 0x10be465  [node]
 6: 0x10be9f4 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
 7: 0x10d58e4 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*) [node]
 8: 0x10d60fc v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 9: 0x10d6e1a v8::internal::Heap::FinalizeIncrementalMarkingIfComplete(v8::internal::GarbageCollectionReason) [node]
10: 0x10d87aa v8::internal::IncrementalMarkingJob::Task::RunInternal() [node]
11: 0xd05a76  [node]
12: 0xd0862f node::PerIsolatePlatformData::FlushForegroundTasksInternal() [node]
13: 0x186cbe3  [node]
14: 0x1880c0b  [node]
15: 0x186d8c7 uv_run [node]
16: 0xbabba6 node::SpinEventLoopInternal(node::Environment*) [node]
17: 0xcdb8c6 node::NodeMainInstance::Run() [node]
18: 0xc467ef node::LoadSnapshotDataAndRun(node::SnapshotData const**, node::InitializationResultImpl const*) [node]
19: 0xc49a12 node::Start(int, char**) [node]
20: 0x76991a0901ca  [/lib/x86_64-linux-gnu/libc.so.6]
21: 0x76991a09028b __libc_start_main [/lib/x86_64-linux-gnu/libc.so.6]
22: 0xba9ade _start [node]
Aborted (core dumped)

[Murderlon]

I'm not ready to do a major version right now as I want to get some other things in for that as well so I'd say we remove AbortSignal.any, it's only used once afaik anyway.

[mitjap]

I agree, removing AbortSignal.any would also resolve #716.

@fenos would you be able to do this?