could you describe an MVP that would form the basis to improve towards the final solution? Or extend the problem description, right now the definition is too vague to propose solutions. E.g. what do the tasks do on startup (computation, IO), how are the specified intervals specified (is it an external input, is it known AOT)

Hey, and sorry about the vague-ness 🙂 The startup is IO (network/promise) and the intervals are defined AOT.

I'm trying to generate load on a UI system for performance testing. This effectively means simulating users in a chat via database writes. The users activity can be described as follows: 1. joining the chat = "startup" 2. sending messages while active 3. sending presence pings while active

So each user is basically a task that continuously executes some simple IO. I was thinking I need to use a flow for the "executing stuff in intervals" but I'm wondering if maybe this also could just be cancellable tasks.

you can run this from the comment block. It concurrently spawns 10 tasks that do some work (you can see the prints in stdout) and shut down after provided ms

> I was thinking I need to use a flow for the "executing stuff in intervals" but I'm wondering if maybe this also could just be cancellable tasks indeed tasks can work as well, in the above prototype loop/recur with an m/sleep inside acts as a long-running task

yeah the loop/recur is nice actually. Thanks for this I think I'm understanding most of it even 🙌

Let me fiddle around a bit more 🙂

Thanks, I managed to get everything working to my liking! ❤️

Very cool that you can just loop recur in an async context like this

Ah — one thing I just noticed I dropped is the m/via m/blk but I think since I'm in cljs-land it probably isn't relevant? (there's no impl for it in missionary.cljc)

glad to help! m/via is for offloading cpu/io-intensive tasks on a JVM thread, so yes, irrelevant in cljs context

erm... as I now incorporated the promises into startup-task things stopped working and now I'm like "how do I convert a promise to a task" but can't find anything in the docs

are the promises third party or can you change the implementation to return tasks?

if not then https://github.com/leonoel/missionary/wiki/Task-interop#futures-promises-1

ultimately they're from a third party library. I would try to convert my functions to tasks, but in the end I'll need to interop with promises.

If you haven't already stumbled across https://github.com/leonoel/task, I'd give it a read – it helped me intuit things like promise interop a bit better

there is also the counterpart https://github.com/leonoel/flow

if you want to fully understand the await-promise implementation I opened a https://github.com/leonoel/missionary/discussions/61 a while back where Dustin links to his https://gist.github.com/dustingetz/d3fb5338b43ef86df5f97387f1d5e249#file-await_promise-clj

oh this is so great, thank you

I remember reading the task spec a while ago actually. And the reasoning for await-promise also makes sense. At the same time it would be nice if it was a bit more out-of-the-box supported to work with promises. In JS it's just the bread and butter of everything

I think Leo tries to keep missionary small and free of helpers. In any case, today you can copy the impl from the wiki page into your codebase 😉

electric repo has a contrib.missionary-contrib ns where i collect the helpers, send them to me and i will add them. will break it out at some point. i try to review all contrib helpers with Leo first

With this kind of code I could see {:sending uid} being tapped and then :sent would never show up. The overall thing (wrapping this with m/race ) would exit successfully. Upon further investigation it turned out that there was a synchronous error in post-chat-msg! that was not surfaced. await-promise was never called, instead the .add line caused the exception.

Interesting... after a REPL restart I can't repro this...

race swallows errors if at least one other input succeeds

Even if the first completed input fails? Would this mean combining m/race with m/sleep would always succeed?

yes. as long as there is still an input running, the race is not over (because there is still a chance to succeed)

Gotcha, what would be the recommended way to fail fast if something fails?

timeout may be exactly what you need

the implementation of timeout uses attempt and absolve for this exact reason