Why do results go out-of-order for an order-by query like this?

SELECT category, round(quantityAvg,0) AS AvgQty, round(priceAvg,2) AS AvgPrice, priceMin, priceMax, totalSales, round(totalInventory,0) AS TotInv FROM ItemsInventory WHERE totalInventory<4000 ORDER BY totalInventory LIMIT 6

Insert, update, and delete callback results from the LiveView API in response to a subscribe() reflect changes to individual rows. The initial snapshot results will be delivered in-order for all rows included in the snapshot. The subsequent continuous updates no longer attempt to maintain ordering.

If the presentation of the results maintains the original "snapshot" order, subsequent updates to individual rows may result in an apparent violation of the ORDER BY order. It is the responsibility of the presentation code, upon receiving a new insert or update, to re-order the received set of rows to maintain the visible order displayed by the client application.

The insert, update, and delete callbacks are called once per tuple (per row). The tuple.id value corresponds the row in the table and is based on the primary key, irrespective of order. When the full set of rows is initially constructed, the values are delivered in ORDER BY column-order during the snapshot phase. The id values may then be used to identify a row for subsequent updates.

As rows in the table are updated, based on the selection criteria (the set of predicate expressions), a row may enter the set, leave the set, or remain in the set with a new value in the ORDER BY field. These changes are trivially reported as they occur without attempting to first emit unchanged rows or provide meta-data about row-to-row ordering. 

The value of the ORDER BY expression is in combination with the LIMIT expression which together determine a subset of the table to which the query applies. This prevents calculating the query result for the entire table or attempting to dump the entire table to the client. The limit is typically between ten and 100 rows, and LiveView performance is optimized for a limit of 30 rows or fewer. The LIMIT expression, when used with ORDER BY, makes sure the query will never exceed a certain size and therefore preserves responsiveness both for the server and the client, even when the table may have millions of rows.

The presentation implementation is responsible for maintaining ordering relationships for the displayed rows.