aglinxinyuan commented on code in PR #6530:
URL: https://github.com/apache/texera/pull/6530#discussion_r3611684470


##########
amber/src/test/python/core/runnables/test_main_loop.py:
##########
@@ -2227,3 +2227,59 @@ class _Executor:
 
         assert rpc_calls == [], "must fail before the jump RPC"
         assert write_log == [], "must fail before touching storage"
+
+    @pytest.mark.timeout(10)
+    def test_two_main_loops_load_distinct_operator_classes(self):
+        """
+        Two MainLoops created in the same process with DIFFERENT operator
+        classes must each load exactly the class they were given.
+
+        Regression test for executor-module contamination (#4705): executor
+        modules were once named ``udf-v<per-instance-counter>``, so every
+        loop's first executor was ``udf-v1`` in the process-wide
+        ``sys.modules``. A loop whose worker never completes never closes its
+        temp fs, so its ``udf-v1.py`` lingered on ``sys.path`` and the next
+        loop re-resolved ``udf-v1`` to that older file, silently running the
+        wrong operator. This test uses NO monkeypatch of
+        ``gen_module_file_name`` -- module names must be process-globally
+        unique on their own.
+        """
+        echo_code = "from pytexera import *\n" + 
inspect.getsource(EchoOperator)
+        count_code = "from pytexera import *\n" + 
inspect.getsource(CountBatchOperator)
+
+        first = MainLoop("worker-first", InternalQueue(), InternalQueue())
+        second = MainLoop("worker-second", InternalQueue(), InternalQueue())

Review Comment:
   Good catch on the leaked daemon threads. Since this regression only 
exercises ExecutorManager (which each MainLoop owns via its Context), I 
switched the test to construct Context directly instead of MainLoop. That keeps 
the module-isolation coverage intact while no longer spawning the per-loop 
DataProcessor thread that a full MainLoop would leave running for the rest of 
the session.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to