From 2b50c45f5775931baec20c3fb440fd1376167c5a Mon Sep 17 00:00:00 2001
From: Alex Koshelev <koshelev@meta.com>
Date: Tue, 31 Oct 2023 15:16:23 -0700
Subject: [PATCH] Fix OPRF attribution and capping circuit

It was using sequential join that limits number of futures driven concurrently to completion. This circuit requires all user-level circuits to be polled, so `parallel_join` is more appropriate

There may be other places where parallel join must be used, I did not check those, this got me to 10k rows.
---
 src/protocol/prf_sharding/mod.rs | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/protocol/prf_sharding/mod.rs b/src/protocol/prf_sharding/mod.rs
index 87832f797..fcca9ab97 100644
--- a/src/protocol/prf_sharding/mod.rs
+++ b/src/protocol/prf_sharding/mod.rs
@@ -29,7 +29,7 @@ use crate::{
         },
         BitDecomposed, Linear as LinearSecretSharing, SharedValue,
     },
-    seq_join::{seq_join, seq_try_join_all},
+    seq_join::seq_join,
 };
 
 pub mod bucket;
@@ -381,7 +381,7 @@ where
             attribution_window_seconds,
         ));
     }
-    let outputs_chunked_by_user = seq_try_join_all(sh_ctx.active_work(), futures).await?;
+    let outputs_chunked_by_user = sh_ctx.parallel_join(futures).await?;
     Ok(outputs_chunked_by_user
         .into_iter()
         .flatten()