Imagine a behavior that depends on the cache. Running the test from scratch will differ from running it when the backend server has been established for some time. The users could have issues when the backend server is shutting down - race conditions that are hard to reproduce.
Without explicitly knowing that a persistent backend server is established, the user might believe this is a spark error, but none of the developers can reproduce the issue with a new state. We should not assume the server will "just work" - it won't. Having a brand new server for every run has its cost, but it's also more deterministic. We won't able to catch every issue with the server with a health checker - any health checker. We will miss some issues, and the server will sometimes be left in a bad state. It's horrible if the user is running some valid code but hit errors because the backend persistent server is in a bad state that we can't recover. All I'm saying is that this is a tradeoff, it has benefits in some cases, but it's not a free lunch. I support having this as a feature when users know what they are doing, aka explicit consent. I'm against making this an implicit default to replace the existing behavior. Tian On Mon, Jun 22, 2026 at 11:09 AM Nicholas Chammas < [email protected]> wrote: > > > On Jun 22, 2026, at 1:14 PM, Tian Gao via dev <[email protected]> > wrote: > > > > I just want to add that an implicitly persistent server might be a > hotbed for nondeterministic behaviors, especially when the background > server has an arbitrary shutdown timeout. I think it's nice to have > something like this when users *explicitly* ask for it. > > Could you elaborate with some examples of what you mean?
