Skip to content

Conversation

@Carreau
Copy link
Member

@Carreau Carreau commented Oct 8, 2025

No description provided.

@Carreau Carreau changed the title Start testing on 3.14 and 3.14-free-threaded Drop 3.9, Start testing on 3.14 and 3.14-free-threaded Oct 9, 2025
@Carreau Carreau force-pushed the 314 branch 4 times, most recently from e57ecba to 338dd19 Compare October 13, 2025 13:08
@Carreau
Copy link
Member Author

Carreau commented Oct 15, 2025

I do not know how to handle or debug the remaining failures.

@minrk
Copy link
Member

minrk commented Oct 15, 2025

@Carreau want me to take this one over? I can have a stab at it.

@Carreau
Copy link
Member Author

Carreau commented Oct 15, 2025

Sure, and feel free to push on my branch. I'm debugging some issues on pytest-jupyter as well.

It might be due to the Event Loop policies deprecation warnings that are the source of the issue.

minrk added 2 commits October 15, 2025 10:02
not really for runtime, but needed for compatibility with recent pytest
@Carreau
Copy link
Member Author

Carreau commented Oct 15, 2025

should all those non-closed sockets and open/close pairs become context manager (in a perfect world).

@minrk
Copy link
Member

minrk commented Oct 15, 2025

should all those non-closed sockets and open/close pairs become context manager (in a perfect world).

Yes, KernelManager and KernelClient should both be context managers.

zmq sockets are already context managers and have been for some time

minrk added 4 commits October 15, 2025 13:03
don't override hatch

doesn't work on windows, let it do the wrong thing
startup sequence seems really slow now
@minrk minrk changed the title Drop 3.9, Start testing on 3.14 and 3.14-free-threaded Drop 3.9, Start testing on 3.14 and 3.14-free-threaded, get tests passing again Oct 16, 2025
@Carreau
Copy link
Member Author

Carreau commented Oct 16, 2025

Restarted MacOS test, failure was intermittent.

Copy link
Member Author

@Carreau Carreau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, a couple of questions, but good as is.

hatch run cov:test --cov-fail-under 75 || hatch run test:test --lf
- name: Run the tests on pypy
echo "PYTEST_ADDOPTS=${PYTEST_ADDOPTS:-} -W default" >> $GITHUB_ENV
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want this to be permanent ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is not a change, it simplifies the 3 different test invocations below by setting the options before using the same pytest invocation.

@minrk
Copy link
Member

minrk commented Oct 16, 2025

green again. One flaky test, still, but passed on re-run.

@Carreau Carreau merged commit bc5d2d5 into jupyter:main Oct 17, 2025
45 of 47 checks passed
rgbkrk added a commit that referenced this pull request Dec 10, 2025
The change in PR #1076 added 'finally: loop.close()' to IOLoopThread.run(),
which closes the asyncio event loop before ZMQ streams have been properly
unregistered. This caused errors during teardown when downstream projects
like qtconsole tried to check if channels were closed.

The fix ensures that channel streams are explicitly closed (via close())
while the ioloop is still running, before calling stop_channels() on the
parent class and stopping the ioloop thread. This allows the ZMQ streams
to be properly unregistered from the event loop before it's closed.
rgbkrk added a commit that referenced this pull request Dec 10, 2025
The change in PR #1076 added 'finally: loop.close()' to IOLoopThread.run(),
which closes the asyncio event loop before ZMQ streams have been properly
unregistered. This caused errors during teardown when downstream projects
like qtconsole tried to check if channels were closed.

The fix ensures that channel streams are explicitly closed (via close())
while the ioloop is still running, before calling stop_channels() on the
parent class and stopping the ioloop thread. This allows the ZMQ streams
to be properly unregistered from the event loop before it's closed.
rgbkrk added a commit that referenced this pull request Dec 10, 2025
…1089)

* Fix channel cleanup by closing streams before stopping ioloop thread

The change in PR #1076 added 'finally: loop.close()' to IOLoopThread.run(),
which closes the asyncio event loop before ZMQ streams have been properly
unregistered. This caused errors during teardown when downstream projects
like qtconsole tried to check if channels were closed.

The fix ensures that channel streams are explicitly closed (via close())
while the ioloop is still running, before calling stop_channels() on the
parent class and stopping the ioloop thread. This allows the ZMQ streams
to be properly unregistered from the event loop before it's closed.

* Fix _exiting to be instance variable, not shared class variable

The _exiting flag was defined as a class variable, meaning when one
IOLoopThread called stop() and set _exiting = True, it affected ALL
IOLoopThread instances. This caused subsequent kernels to fail to start
because _async_run() would immediately exit.

By initializing self._exiting = False in __init__, each IOLoopThread
instance now has its own exit flag. The class-level _exiting is still
used by _notice_exit() for interpreter shutdown cleanup.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants