Jack McCluskey

Looking into this a little bit, it's doable for each handler type but the end result is somewhat restrictive for the user. The provided function is going to have to...

I've put together a brief doc discussing my perspective and preferred solution for this here - https://docs.google.com/document/d/1YYGsF20kminz7j9ifFdCD5WQwVl8aTeCo0cgPjbdFNU/edit?usp=sharing PTAL

The Go ValidatesRunner suite seems to be failing with timeouts for each test.

Filed as #24334

Not something I'm familiar with, although I wouldn't be surprised if the interactive runner didn't support multithreading.

Double-checked, neither supports multithreading at the moment. You can file a feature request for Beam, but I couldn't tell you if that would be picked up any time soon

Coming at it from the Beam metric side, it looks like numpy.int64 values are being passed to the counter improperly somewhere. Those counters should only receive ints, as that is...

I'm looking into this right now along with #23366 (which points out that we currently do not handle the built-in `tuple` correctly when used as a parameterized generic) and hope...

I'm actually having a bit of trouble reproducing the error described here and in https://github.com/pangeo-forge/pangeo-forge-recipes/pull/470. The only 0-arity types we handle are `typing.NewType`, `typing.ForwardRef`, `typing.Any`, and `typing.NamedTuple` but I'm not...

Has any progress been made on this?