Hot reload with long running tasks

[maartenbreddels]

A long running task can keeps running after a hot reload, which can be confusing. In our case we had a lot of SQLAlchemy errors because we had old and new classes being mixed. Crucial here is to detect if we did a hot reload, or if the current task is still running (the latter should be enough if it did not crash)

[SAKSHI-DOT693]

This is a good catch. The confusing behavior isn’t the presence of long-running tasks themselves, but that they can silently outlive a hot reload while the Python module state is re-created.

The SQLAlchemy errors you mentioned fit this model: tasks started before the reload keep references to old class definitions, while the application continues with newly imported ones.

Architecturally, this seems less like a task-management problem and more like a missing lifecycle boundary around hot reloads. Either background tasks need to be explicitly invalidated when a reload occurs, or they should be bound to a specific runtime instance so they cannot interact with state created after a reload.

I’m investigating where Solara detects or initiates hot reloads, and whether there’s a reliable hook to mark an execution context as stale versus a task that is still legitimately running. I’ll follow up with findings or a concrete proposal once I’ve traced that path.

[SAKSHI-DOT693]

I’ve been digging into the reload behavior and task lifecycle to better understand the intended boundaries.

From what I can see, create_reload_checker() already acts as the authority for detecting when a runtime reload has occurred, but background tasks created via use_task / use_thread don’t currently have a mechanism to invalidate themselves once that happens.

My proposal is intentionally minimal: capture a reload token when the task starts, and have the task runner / scheduler loop compare this token before continuing execution. When a reload occurs and the token changes, the task exits cleanly.

This keeps reload semantics centralized in the task runner (rather than inside user code), aligns with the model where reload resets execution context, and avoids introducing any new global state or abstractions.

Before implementing, I wanted to confirm that placing this check at the task runner / scheduler level matches how you’d expect reload lifecycle to be enforced.