fix: shutdown order of connected clients

[callicles]

Note

Overhauls shutdown sequencing: gracefully close HTTP, stop app processes, flush/drop Kafka clients (waiting for librdkafka destroy), and then stop containers; adds cancellable sync processes and minor DX tweaks.

• Runtime/Shutdown:
  • Graceful HTTP shutdown with environment-appropriate timeouts; drop services after connections drain.
  • Flush and drop Kafka producer; wait for librdkafka teardown via rd_kafka_wait_destroyed (adds rdkafka-sys).
  • Reorders shutdown: stop managed processes/workflows, add grace periods, then stop Docker containers.
  • Improved SIGINT/SIGTERM feedback; final “shutdown complete” messaging.
• Kafka Sync Processes:
  • Add cancellable sync tasks (topic→table, topic→topic) with oneshot cancel and grace-period waits.
  • New SyncingProcessesRegistry::stop_all(); integrates into central ProcessRegistries and shutdown path.
  • Sync loops honor cancellation via select! and flush pending work before exit.
• Process Registry/API:
  • ProcessRegistries now owns syncing registry; stop() also halts syncing processes.
  • execute_initial_infra_change/execute_online_change APIs updated to remove external syncing param and return/use unified registry.
  • Watcher/routines updated accordingly (no separate syncing registry threading).
• Webserver:
  • configured_producer wrapped in Arc; router/ingest signatures updated.
  • Producer flush on shutdown; HTTP cleanup grace, then process/infra cleanup.
• System utilities:
  • kill_child now SIGTERM then waits with timeout; escalates to SIGKILL if needed; RestartingProcess updated.
• TypeScript (cluster utils):
  • Worker shutdown only calls workerStop if startup completed.

^{Written by Cursor Bugbot for commit ab6f948. This will update automatically on new commits. Configure here.}

[linear]

ENG-961 Streaming function processes not properly shutdown during `moose dev` exit

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
framework-docs	Ready	Preview	Comment	Oct 10, 2025 6:36pm

[onelesd]

feels like a good improvement to more graceful shutdown.

in the flushing kafka w/ a timeout case- if it takes longer than the timeout might we lose data? does it make sense to flush to disk and reload on startup?

[callicles]

In a container env we won't have the disk. But we only ack to the source if the data was written.
So that guarantees that if things did not make it we will retry. We have at least once delivery so duplictaes are ok

[phiSgr]

the kafka producer has an Arc internally so it's cheaply clone-able, no need for an extra Arc