Changelog category (leave one):

• Bug Fix (user-visible misbehavior in an official stable release)

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Fixes incorrect row ordering in queries that use ORDER BY with the grace_hash join algorithm. Affected queries could return results in the wrong order, producing silently incorrect output.

Documentation entry for user-facing changes

• Documentation is written (mandatory for new features)

Claude explanation:
Root Cause

The bug is in src/Processors/QueryPlan/Optimizations/optimizeReadInOrder.cpp, in the findReadingStep function (line 150). The optimize_read_in_order optimization propagates the "data is sorted" property through JOIN steps,
allowing the final ORDER BY to skip a full sort and rely on the MergeTree's key ordering. However, this optimization checked only the join kind (Inner/Left) and strictness (Any/All) — it never verified whether the join algorithm
preserves input row order.

Grace hash join destroys input order because it scatters rows into buckets by hash value. Rows from bucket 0 come first, then bucket 1, etc. — this has nothing to do with the original sort key order. When the sorting step relies
on a "prefix sort" (assuming data is already ordered), the output comes out in hash-bucket order rather than key order.

The Fix

One-line change: add && !join_ptr->hasDelayedBlocks() to the condition that allows read-in-order through joins. Joins with delayed blocks (grace hash join) reorder rows, so the optimization must not propagate through them.
Regular HashJoin and ConcurrentHashJoin process rows in a single pass preserving order, so they remain unaffected.