From 021bb387fce1dc1b3c2aa4bc5de47aed8a984652 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 bf3e385c..60293716 100644
--- a/tractor/_portal.py
+++ b/tractor/_portal.py
@@ -380,6 +380,7 @@ async def open_context(
 
         self,
         func: Callable,
+        allow_overruns: bool = False,
         **kwargs,
 
     ) -> AsyncGenerator[tuple[Context, Any], None]:
@@ -409,6 +410,16 @@ async def open_context(
             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'