Offirmo

cleanly monitor worker.disconnect and server.close

1

instead of try/catching `server.close` and `worker.disconnect`, we could listen to their `close` and `disconnect` signal and abstain from repeating if already closed / shut. More elegant I think. PR pending.

interference between server.close and worker.disconnect

1

According to node documentation, calling `worker.disconnect()` will close existing servers. And that's true (tested it) Calling `worker.disconnect()`will even throw an uncaught if the servers are already closed (tested it also)....

disconnecting the worker after a server error

2

For what I see in the code, if the call to `server.close` fail, the cluster worker won't be disconnected. This could be made stronger.

closing the server when not in cluster

2

For what I can see in the code, the current code won't attempt to close the server when not in a cluster. This is questionable (though I can think of...

allowing a custom shutdown callback

2

This would allow : - customizing the shutdown procedure (sending an email, etc.) - reusing the callback in other shutdown cases (kill signal received, software shutdown)

With my graph using coordinates between 400 and 3000, nothing is displayed at first, and I have to unzoom and scroll. Should be done automatically.

For example, I find it extremely difficult to understand where the widget is looking for the .gexf file. The name of the file is briefly displayed. It should remain or...

Clear enough.

Just wanted to say thank you for this resource

1

### Please describe your problem or observation I'm upskilling in AI and I found this guide very interesting. Also using "colab" is very convenient. ### Describe the solution you'd like...