Polars 2.0's streaming default can reorder group_by and join output without an error

Code that never passed an engine argument is running engine="auto". In 2.0 that setting resolves to streaming for both LazyFrame.collect() and collect_async() ^[1]. Eager DataFrame code does not move ^[3]. According to the dev.to guide, streaming uses less memory on large data and executes differently ^[15].

The guide's advice is to pin the in-memory engine, run the tests, then remove the pin one pipeline at a time ^[16]. There are three places to pin: engine="in-memory" on a single call, pl.Config.set_engine_affinity("in-memory") in code, or POLARS_ENGINE_AFFINITY=in-memory in the environment ^[4]. I'd start with the environment variable, as the guide does. It changes no source file, so the whole suite runs against 2.0 before anyone edits code ^[5]. In a repository where CI runs every pipeline's tests, that splits the upgrade into two experiments. Failures with the pin set come from API changes. The guide says those fail fast and are easy to fix ^[19]. Anything that breaks after a pipeline is unpinned comes from the engine ^[20]. Deployment config needs one edit either way: POLARS_STREAMING_CHUNK_SIZE is now POLARS_IDEAL_MORSEL_SIZE ^[6].

The pin covers the engine behind collect() and nothing else ^[21]. Casts tighten regardless. Integer to Categorical and back is disallowed, as is String to Date, Datetime or Time, and the replacement is the explicit parser ^[13]. A list passed to schema_overrides must now cover every column ^[11]. The guide also says a selector expression that used to mean a set intersection now means something else ^[14]. Running on the old engine does not bring the old meaning back ^[21].

For row order the guide offers three fixes: maintain_order=True on group_by, maintain_order="left" on a left join, or a sort at the end of the query ^[8]. It prefers the final sort as cheaper to reason about than preserving order inside every operation ^[17]. For report pipelines I agree. One sort at the output boundary is one line to review, while maintain_order is a flag someone has to remember on each operation. The guide's list of exposed steps includes a CSV that a human diffed ^[7]. That reviewer is an assertion library with no version pin. The guide also says to keep check_row_order on in assert_frame_equal and let the failures show where order mattered ^[9]. Streaming output can differ between runs ^[7], so a single green run with that check on proves little, and I would repeat the comparison before removing a pin.

Horizontal concat is the change both safeguards can miss. The engine pin does not touch it ^[21]. The guide says it is loud only when tests use frames of uneven height ^[18]. A suite whose fixtures always had matching heights passes, and the pipeline fails in production the day an upstream filter returns fewer rows ^[18].