gitlab-runner tests run through fine locally but hang on gitlab.com

[robert-cronin]

This is the last output on the pipeline:

Jest did not exit one second after the test run has completed.
This usually means that there are asynchronous operations that weren't stopped in your tests. Consider running Jest with `--detectOpenHandles` to troubleshoot this issue.

There re no open handles detected when running locally so I am not sure what is happening here.

[CMCDragonkai]

This can happen if an async test wasn't properly structured/awaited for. You should have a look around.

[robert-cronin]

yeah it's most likely either worker-threads not exiting or a polykey agent not winding down so we will have to deal with tear down properly.

[robert-cronin]

This has been solve, the issue was that there was UDP sockets continuously broadcasting their peers presence on the multicast address and was not stopping upon the termination of the agent process. Simple fix was to use clearInterval to stop the broadcasting and allow the socket to disconnect.

[CMCDragonkai]

Should indicate in the PR that fixes this.

[CMCDragonkai]

Do you know about RAII? It's important way of managing resources like sockets for OOP languages. Also we might find a bracket pattern. Problem is that JS objects don't have a destructor. But I worked around this in js-virtualfs using things like ref links in resource counter and having managing classes that would explicitly close/destroy things on some counter.

[robert-cronin]

yeah I know about RAII, it didn't help much in this situation, the agent process was killed and it's corresponding JS object even set to undefined after the tests but it didn't work.
So perhaps we can do something similar to VFS but the issue was that the UDP socket is constantly broadcasting and there's no counter mechanism that would make sense here. Anyway, it's now all taken care in the agent.stop() function and it makes sense to me that agent should have an explicit destructor function as it's not tied to any RAII of the polykey class and designed to run forever as a daemon process.

[CMCDragonkai]

Yea in that case, the explicit stop command should be executed on OS signals.

So you need https://nodejs.org/api/process.html#process_signal_events for this.

At least on the CLI that is.

The relevant signals are:

SIGINT
SIGTERM
SIGQUIT
SIGHUP

They all mean slightly different things.

Generally SIGINT for our app will mean to close it gracefully. Same with SIGTERM. So we will do the same thing for both signals. Perform a graceful shutdown. The only case where SIGINT deviates from SIGTERM is when we are trying to interrupt polykey when it is doing something and we want to reset back to idle state. But that only occurs for apps that run apps like shells.

For SIGHUP:

The SIGHUP signal is sent to a process when its controlling terminal is closed. It was originally designed to notify the process of a serial line drop (a hangup). In modern systems, this signal usually means that the controlling pseudo or virtual terminal has been closed.[7] Many daemons will reload their configuration files and reopen their logfiles instead of exiting when receiving this signal.[8] nohup is a command to make a command ignore the signal.

So for now you just have to handle SIGINT and SIGTERM in the CLI.

The GUI will have similar situations too, but only for desktop. Not sure for Android/iOS.