Long running process exits with IOSelectorsException

Start in nmqtt.nim around runConnect and connectBroker, then trace the asyncnet/asyncdispatch registration path shown in the stack trace. Reproduce the long-running start/disconnect sequence, including the missing try/finally cleanup, and determine whether descriptor exhaustion comes from nmqtt or the caller. Done means identifying the leak source and covering the lifecycle with a focused regression test or documented cleanup requirement.

I have a program which runs for a long time, every once in a time sending something over MQTT. Recently I got a crash with this error message:

  /home/peter/.choosenim/toolchains/nim-2.0.0/lib/pure/asyncdispatch.nim(2022) waitFor
  /home/peter/.choosenim/toolchains/nim-2.0.0/lib/pure/asyncdispatch.nim(1711) poll
  /home/peter/.choosenim/toolchains/nim-2.0.0/lib/pure/asyncdispatch.nim(1452) runOnce
  /home/peter/.choosenim/toolchains/nim-2.0.0/lib/pure/asyncdispatch.nim(269) processPendingCallbacks
  /home/peter/.nimble/pkgs2/nmqtt-1.0.5-e9b66114ab9f39559f01e200164bfff921c0c8f3/nmqtt.nim(1094) runConnect (Async)
  /home/peter/.nimble/pkgs2/nmqtt-1.0.5-e9b66114ab9f39559f01e200164bfff921c0c8f3/nmqtt.nim(1066) connectBroker (Async)
  /home/peter/.choosenim/toolchains/nim-2.0.0/lib/pure/asyncnet.nim(296) dial (Async)
  /home/peter/.choosenim/toolchains/nim-2.0.0/lib/pure/asyncdispatch.nim(1902) dial
  /home/peter/.choosenim/toolchains/nim-2.0.0/lib/pure/asyncdispatch.nim(1868) tryNextAddrInfo
  /home/peter/.choosenim/toolchains/nim-2.0.0/lib/pure/asyncdispatch.nim(1733) createAsyncNativeSocket
  /home/peter/.choosenim/toolchains/nim-2.0.0/lib/pure/asyncdispatch.nim(1247) register
  /home/peter/.choosenim/toolchains/nim-2.0.0/lib/pure/ioselects/ioselectors_epoll.nim(136) registerHandle
  /home/peter/.choosenim/toolchains/nim-2.0.0/lib/pure/selectors.nim(287) raiseIOSelectorsError
Exception message: Maximum number of descriptors is exhausted!
 [IOSelectorsException]

Might be something else in my program which leaks descriptors, but figured I'd report it here first since the error was triggered in nmqtt. The MqttContext lives for the lifetime of the program, and the messages are sent wrapped in a start/disconnect construct (but not in a try/finally one).