test(celery): faulthandler dump child stacks on beat hang

The pidfile-race fix did not unhang py3.7 celery in CI. pytest-timeout
only dumps the parent pytest process's threads — the parent is stuck in
pytest-forked's waitpid, so the actual hang is somewhere inside the
forked child, invisible.

Schedule faulthandler.dump_traceback_later(45) in run_beat (which runs
inside the forked child) and cancel it on successful beat shutdown. If
beat hangs in CI again, the child's full thread dump lands in the log
and tells us where to look.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: sl0thentr0py

tests/integrations/celery/integration_tests/__init__.py

@@ -1,3 +1,4 @@
+import faulthandler
 import os
 import signal
 import sys
@@ -65,6 +66,12 @@ def run_beat(celery_app, runtime_seconds=1, loglevel="warning", quiet=True):
     Run Celery Beat that immediately starts tasks.
     The Celery Beat instance is automatically terminated after `runtime_seconds`.
     """
+    # If anything below wedges this (forked) child process, dump all of its
+    # thread stacks to stderr and exit, so a future hang surfaces a diagnosis
+    # in the CI log instead of just stalling pytest-forked's waitpid in the
+    # parent. Generous budget: kill_beat itself can wait up to ~30s for the
+    # pidfile, plus runtime_seconds, plus celery beat shutdown.
+    faulthandler.dump_traceback_later(45, exit=True)
     logger.info("Starting Celery Beat...")
     pid_file = os.path.join(tempfile.mkdtemp(), f"celery-beat-{os.getpid()}.pid")
 
@@ -80,4 +87,7 @@ def run_beat(celery_app, runtime_seconds=1, loglevel="warning", quiet=True):
         quiet=quiet,
         pidfile=pid_file,
     )
-    beat_instance.run()
+    try:
+        beat_instance.run()
+    finally:
+        faulthandler.cancel_dump_traceback_later()