Skip to content

test(integration): expand numeric ORE ordering tests with edge cases #377

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tobyhede merged 10 commits into from
Mar 24, 2026
Merged

test(integration): expand numeric ORE ordering tests with edge cases #377

Changes from 3 commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
920f991
test(integration): expand numeric ORE ordering tests with edge cases
tobyhede Mar 4, 2026
cddf2c7
style: apply cargo fmt to ORE ordering tests
tobyhede Mar 4, 2026
e19d40a
fix(integration): replace 3.14 with 3.25 to avoid clippy approx_const…
tobyhede Mar 4, 2026
bdd5d63
test(integration): add multitenant ORE ordering tests for all tenant …
tobyhede Mar 4, 2026
76d611d
refactor(integration): deduplicate ORE ordering test helpers
tobyhede Mar 4, 2026
f207300
fix(integration): serialize ORE ordering tests and add SortDirection …
tobyhede Mar 4, 2026
63b478c
test(integration): use lexicographic edge cases in ORE text ordering …
tobyhede Mar 5, 2026
29e571e
fix: bump metrics crate to 0.24.3 to fix Rust compiler error
tobyhede Mar 5, 2026
637a221
fix(integration): use arrays instead of vec! for clippy useless_vec lint
tobyhede Mar 6, 2026
e82da17
fix: how to even alphabet
tobyhede Mar 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
222 changes: 90 additions & 132 deletions packages/cipherstash-proxy-integration/src/map_ore_index_order.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
#[cfg(test)]
mod tests {
use std::fmt::Debug;
use tokio_postgres::types::{FromSql, ToSql};
use tokio_postgres::SimpleQueryMessage;

use crate::common::{clear, connect_with_tls, random_id, trace, PROXY};
Expand Down Expand Up @@ -417,164 +419,120 @@ mod tests {

#[tokio::test]
async fn map_ore_order_int2() {
trace();

clear().await;

let client = connect_with_tls(PROXY).await;

let n_one = 10i16;
let n_two = 20i16;
let n_three = 30i16;

let sql = "
INSERT INTO encrypted (id, encrypted_int2)
VALUES ($1, $2), ($3, $4), ($5, $6)
";

client
.query(
sql,
&[
&random_id(),
&n_two,
&random_id(),
&n_one,
&random_id(),
&n_three,
],
)
.await
.unwrap();

let sql = "SELECT encrypted_int2 FROM encrypted ORDER BY encrypted_int2";
let rows = client.query(sql, &[]).await.unwrap();

let actual = rows.iter().map(|row| row.get(0)).collect::<Vec<i16>>();
let expected = vec![n_one, n_two, n_three];

assert_eq!(actual, expected);
let values: Vec<i16> = vec![-100, -10, -1, 0, 1, 5, 10, 20, 100, 200];
map_ore_order_generic("encrypted_int2", values, "ASC").await;
}

#[tokio::test]
async fn map_ore_order_int2_desc() {
trace();

clear().await;

let client = connect_with_tls(PROXY).await;

let n_one = 10i16;
let n_two = 20i16;
let n_three = 30i16;

let sql = "
INSERT INTO encrypted (id, encrypted_int2)
VALUES ($1, $2), ($3, $4), ($5, $6)
";

client
.query(
sql,
&[
&random_id(),
&n_two,
&random_id(),
&n_one,
&random_id(),
&n_three,
],
)
.await
.unwrap();

let sql = "SELECT encrypted_int2 FROM encrypted ORDER BY encrypted_int2 DESC";
let rows = client.query(sql, &[]).await.unwrap();

let actual = rows.iter().map(|row| row.get(0)).collect::<Vec<i16>>();
let expected = vec![n_three, n_two, n_one];

assert_eq!(actual, expected);
let values: Vec<i16> = vec![-100, -10, -1, 0, 1, 5, 10, 20, 100, 200];
map_ore_order_generic("encrypted_int2", values, "DESC").await;
}

#[tokio::test]
async fn map_ore_order_int4() {
trace();

clear().await;

let client = connect_with_tls(PROXY).await;
let values: Vec<i32> = vec![
-50_000, -1_000, -1, 0, 1, 42, 1_000, 10_000, 50_000, 100_000,
];
map_ore_order_generic("encrypted_int4", values, "ASC").await;
}

let n_one = 10i32;
let n_two = 20i32;
let n_three = 30i32;
#[tokio::test]
async fn map_ore_order_int4_desc() {
let values: Vec<i32> = vec![
-50_000, -1_000, -1, 0, 1, 42, 1_000, 10_000, 50_000, 100_000,
];
map_ore_order_generic("encrypted_int4", values, "DESC").await;
}

let sql = "
INSERT INTO encrypted (id, encrypted_int4)
VALUES ($1, $2), ($3, $4), ($5, $6)
";
#[tokio::test]
async fn map_ore_order_int8() {
let values: Vec<i64> = vec![
-1_000_000, -10_000, -1, 0, 1, 42, 10_000, 100_000, 1_000_000, 9_999_999,
];
map_ore_order_generic("encrypted_int8", values, "ASC").await;
}

client
.query(
sql,
&[
&random_id(),
&n_two,
&random_id(),
&n_one,
&random_id(),
&n_three,
],
)
.await
.unwrap();
#[tokio::test]
async fn map_ore_order_int8_desc() {
let values: Vec<i64> = vec![
-1_000_000, -10_000, -1, 0, 1, 42, 10_000, 100_000, 1_000_000, 9_999_999,
];
map_ore_order_generic("encrypted_int8", values, "DESC").await;
}

let sql = "SELECT encrypted_int4 FROM encrypted ORDER BY encrypted_int4";
let rows = client.query(sql, &[]).await.unwrap();
#[tokio::test]
async fn map_ore_order_float8() {
let values: Vec<f64> = vec![
-99.9, -1.5, -0.001, 0.0, 0.001, 1.5, 3.25, 42.0, 99.9, 1000.5,
];
map_ore_order_generic("encrypted_float8", values, "ASC").await;
}

let actual = rows.iter().map(|row| row.get(0)).collect::<Vec<i32>>();
let expected = vec![n_one, n_two, n_three];
#[tokio::test]
async fn map_ore_order_float8_desc() {
let values: Vec<f64> = vec![
-99.9, -1.5, -0.001, 0.0, 0.001, 1.5, 3.25, 42.0, 99.9, 1000.5,
];
map_ore_order_generic("encrypted_float8", values, "DESC").await;
}

assert_eq!(actual, expected);
/// Returns indices in zigzag order so insertion is never accidentally sorted.
/// For len=5: [4, 0, 3, 1, 2]
fn interleaved_indices(len: usize) -> Vec<usize> {
let mut indices = Vec::with_capacity(len);
let mut lo = 0;
let mut hi = len;
let mut take_hi = true;
while lo < hi {
if take_hi {
hi -= 1;
indices.push(hi);
} else {
indices.push(lo);
lo += 1;
}
take_hi = !take_hi;
}
indices
}

#[tokio::test]
async fn map_ore_order_int8() {
/// Generic ORE ordering test.
///
/// `values` must be provided in ascending sorted order.
/// Values are inserted in interleaved (non-sorted) order, then verified
/// via ORDER BY in the given direction.
async fn map_ore_order_generic<T>(col_name: &str, values: Vec<T>, direction: &str)
Copy link
Copy Markdown
Contributor

@coderdan coderdan Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these tests run with the same key every time? My guess is that they would be.
To test ORE behaviour definitively, the tests should run with many different keys.

Copy link
Copy Markdown
Contributor Author

@tobyhede tobyhede Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@coderdan Not sure what you mean

Copy link
Copy Markdown
Contributor

@coderdan coderdan Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When an ORE value is encrypted, it uses a key.

2 encrypted values will compare correctly if they were encrypted with the same key.
If they were encrypted with different keys then they will compare correctly 50% of the time.

I'm suggesting that the tests need to encrypt a bunch of values with key a, check that they compare correctly then do it again with a different key, b and make sure they still compare correctly.

One way to do this would be to randomly generate the key used for every test run so that we build confidence over many CI runs. Another way would be to use property testing to do many runs in a single CI run.

Copy link
Copy Markdown
Contributor

@freshtonic freshtonic Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@coderdan the Proxy tests run using a Workspace that survives across test runs - which means they would be using the same Keyset across test runs.

Given that a broken ORE integration with Proxy could false positive "pass" an assertion of a comparison op with 50/50 odds, and the ORE is deterministic with respect to the keyset material I can see that it would in principal be possible to be convinced something is working when it isn't.

But even though the key is unchanging between test runs we are encrypting multiple different values in this test and ensuring they sort correctly. I would have thought that if ORE integration was broken then the odds of a false positive would halve for every seperate value in the values being sorted?

Copy link
Copy Markdown
Contributor

@coderdan coderdan Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One way to do this in the proxy context would be to run the test for multiple different keysets.

Copy link
Copy Markdown
Contributor Author

@tobyhede tobyhede Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@coderdan @freshtonic
Added ore ordering to the multitenant test context:
packages/cipherstash-proxy-integration/src/multitenant/ore_order.rs

Runs the tests against 3 tenant keysets.
Original ORE tests remain, and they test the default keyset.

where
for<'a> T: Clone + PartialEq + ToSql + Sync + FromSql<'a> + PartialOrd + Debug,
{
trace();

clear().await;

let client = connect_with_tls(PROXY).await;

let n_one = 10i64;
let n_two = 20i64;
let n_three = 30i64;
let insert_sql = format!("INSERT INTO encrypted (id, {col_name}) VALUES ($1, $2)");

let sql = "
INSERT INTO encrypted (id, encrypted_int8)
VALUES ($1, $2), ($3, $4), ($5, $6)
";
// Insert in interleaved order to avoid accidentally-sorted insertion
for idx in interleaved_indices(values.len()) {
client
.query(&insert_sql, &[&random_id(), &values[idx]])
.await
.unwrap();
}

client
.query(
sql,
&[
&random_id(),
&n_two,
&random_id(),
&n_one,
&random_id(),
&n_three,
],
)
.await
.unwrap();
let select_sql =
format!("SELECT {col_name} FROM encrypted ORDER BY {col_name} {direction}");
let rows = client.query(&select_sql, &[]).await.unwrap();

let sql = "SELECT encrypted_int8 FROM encrypted ORDER BY encrypted_int8";
let rows = client.query(sql, &[]).await.unwrap();
let actual: Vec<T> = rows.iter().map(|row| row.get(0)).collect();

let actual = rows.iter().map(|row| row.get(0)).collect::<Vec<i64>>();
let expected = vec![n_one, n_two, n_three];
let expected: Vec<T> = if direction == "DESC" {
values.into_iter().rev().collect()
} else {
values
};

assert_eq!(actual, expected);
}
Expand Down