I have been integrating coroutines with the GraphQ...

# coroutines

[David Glasser]

I have been integrating coroutines with the GraphQL-Java async API, which requires certain functions that I implement to return CompletableFutures. For unfortunate reasons, there are certain methods (this is the DataLoader API if you know GraphQL-Java) that I am only allowed to call synchronously from my functions that returns the CompletableFuture, not later.

I've implemented this as a wrapper around a suspend function (eg fetcher), like this:

return someCoroutineScope.future(start = UNDISPATCHED) { fetcher() }

UNDISPATCHED has exactly the semantics I need — the code in fetcher can safely call the "only before suspending" DataLoader methods as long as it does so before suspending.

This works in the sense that it allows me to write code that works. However, if I make an error and call a DataLoader method after having suspended, my code just hangs (because that's the symptom I'm trying to avoid). I'd prefer that it failed fast. (Well, I'd really prefer that none of this junk was necessary, there's an issue on the library about fixing it... but trying to work around today.)

So my question is: If I'm running code inside the context of a CoroutineScope.future(start = UNDISPATCHED) { ... }, is there any way to know if I'm still in the undispatched part of the execution? (Happy to track this state in a boolean or something if there's a way to get a hook on dispatch.)

[David Glasser]

I guess one way of looking at this is can I put a hook in a block that's running in an UNDISPATCHED coroutine that triggers on suspend or resume?

[David Glasser]

Oh duh. It is literally the first thing I tried, which is "after the future() call returns", except that my test code had some unrelated issues