From ead9e418de8c131dc48c3ad3565e9f1752bfdf10 Mon Sep 17 00:00:00 2001
From: Tyler Goodlet <jgbt@protonmail.com>
Date: Fri, 12 May 2023 18:28:47 -0400
Subject: [PATCH] Expose `allow_overruns` to `Portal.open_context()`

Turns out you can get a case where you might be opening multiple
ctx-streams concurrently and during the context opening phase you block
for all contexts to open, but then when you eventually start opening
streams some slow to start context has caused the others become in an
overrun state.. so we need to let the caller control whether that's an
error ;)

This also needs a test!
---
 tractor/_portal.py | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/tractor/_portal.py b/tractor/_portal.py
index bf3e385..6029371 100644
--- a/tractor/_portal.py
+++ b/tractor/_portal.py
@@ -380,6 +380,7 @@ class Portal:
 
         self,
         func: Callable,
+        allow_overruns: bool = False,
         **kwargs,
 
     ) -> AsyncGenerator[tuple[Context, Any], None]:
@@ -409,6 +410,16 @@ class Portal:
             fn_mod_path,
             fn_name,
             kwargs,
+
+            # NOTE: it's imporant to expose this since you might
+            # get the case where the parent who opened the context does
+            # not open a stream until after some slow startup/init
+            # period, in which case when the first msg is read from
+            # the feeder mem chan, say when first calling
+            # `Context.open_stream(allow_overruns=True)`, the overrun condition will be
+            # raised before any ignoring of overflow msgs can take
+            # place..
+            allow_overruns=allow_overruns,
         )
 
         assert ctx._remote_func_type == 'context'