mjsteger

So, I'm able to get to a point where the futures are under some number of layers(by having an activity which fails at first but eventually succeeds, as you suggested),...

@nabeelamjad sorry to hear about your experience :(. I'm not able to personally replicate the memory leak: what I've tried so far is to run the booking example's "starter.rb" a...

@nabeelamjad glad to hear it! The docs should definitely be changed and/or drill_on_future should be changed to accept a list of arguments(though, I'd argue that in future versions, the default...

That's definitely pretty worrisome. It sounds like you weren't running that many workers and still getting an accretion of memory. There definitely don't appear to be a lot of longer...

Well, glad to hear that they are looking into it. Thanks for keeping me abreast, that's definitely a problem I was not looking forward to debugging. Out of curiosity, were...

You're right that we should tighten down the requires so that 1.8.7 can launch workflows. In theory, activity workers should also be able to function fine without Fibers. I'll try...

Still working on this. The "easy" solution would be to autoload fibers, which would neatly allow you to use all the clients which don't need fibers in 1.8 without much...

Are there any known workarounds? I'm a little leery special casing a fix via say, replacing NameError::message with a string, as it may then make us unable to take a...

We have a couple possible candidate fixes to this, one of which will hopefully go out soon. Just letting you know we're still working on fixing this.

At first glance, looks like an issue with using trap context in a way that is deadlockable(see [this](https://bugs.ruby-lang.org/issues/7917)). In theory flow workers are supposed to have a graceful shutdown mechanic,...