Fix true_valid_to updating

[m-sz]

Description

true_valid_to is not always updated as needed. It can happen that ethflow order events are parsed first, before order creation takes place which results in true_valid_to to first be set correctly, and then set to u32::MAX when inserting the order.

Changes

Adds a clause

COALESCE(
	(SELECT LEAST($21, valid_to) FROM ethflow_orders WHERE uid = $1),
	$21
)

to INSERT_ORDER query which will always take the smallest of ethflow_orders.valid_to and the value currently being inserted.

How to test

Tested on ethflow E2E test local_node_eth_flow_tx confirmed the faulty behaviour can occur and added assert that ensures the resulting true_valid_to is not u32::MAX

[gemini-code-assist]

Code Review

This pull request addresses a race condition where true_valid_to for ethflow orders could be incorrectly set. The fix modifies the order insertion query to conditionally use the valid_to from the ethflow_orders table, which correctly handles out-of-order event processing. The logic is sound and is well-covered by a new end-to-end test assertion. I have one minor suggestion to improve a comment for clarity.

[m-sz]

Verified on staging mainnet:

Before the deployment:
https://barn.explorer.cow.fi/orders/0x319a17861f5d40a50c99e0cd3821f0278a65b1d8f50efd31b[…]b1f170d36a04501b9b1d52e67f6862d157e00d13419d2d6e95ffffffff
https://barn.explorer.cow.fi/orders/0xe7a70e6ed59c3f40c2e78530e7b1ceba2ce5486c349abdd4a[…]2bb66e794704501b9b1d52e67f6862d157e00d13419d2d6e95ffffffff

Both got set true_valid_to to u32::MAX

After the deployment:
https://barn.explorer.cow.fi/orders/0xa8061d917531484d528329e6d6b99cc8bb7020d3436cdd8f4[…]6a8e78203604501b9b1d52e67f6862d157e00d13419d2d6e95ffffffff
https://barn.explorer.cow.fi/orders/0xbd96aa0e214ab5f6e41276e1ad69025dcc22ce09f0e5c18cb[…]1b03d32fb004501b9b1d52e67f6862d157e00d13419d2d6e95ffffffff

have correct true_valid_to

[gemini-code-assist]

Code Review

This pull request addresses a race condition where true_valid_to for an order could be incorrectly set. The fix modifies the INSERT query for orders to ensure the correct validity period is chosen if an ethflow_orders entry already exists. The accompanying E2E test verifies this fix. However, a similar critical issue exists on the UPDATE path in a related file, which is not addressed by this PR. I've added a comment detailing this issue and a suggested fix to ensure the logic is robust across all code paths.

[gemini-code-assist]

This change correctly handles true_valid_to on INSERT. However, a related race condition on the UPDATE path remains, which can lead to incorrect order validity.

The function insert_or_overwrite_ethflow_order in crates/database/src/ethflow_orders.rs uses a direct UPDATE which can overwrite a correct, smaller true_valid_to with a larger one. This is a critical issue as it can make expired orders appear solvable.

To ensure data consistency, the update logic should be consistent with this insert logic. Please also update the query in crates/database/src/ethflow_orders.rs to use LEAST and COALESCE to robustly handle NULL values and race conditions:

UPDATE orders
SET true_valid_to = LEAST(COALESCE(true_valid_to, $1), $1)
WHERE uid = $2

[m-sz]

The ethflow orders valid to is preferred when order is inserted. We only have to guard against a case when order is inserted after the ethflow event has been parsed which would previously result in the validity being u32::MAX