ExtendedTask concludes with error but mirai still unresolved

[James-G-Hill]

Hello, I wondered if anyone had seen a problem similar to this.

I have a process in my application where:

• a user can create an object (R6 class) with some large data
• the object is passed to an ExtendedTask
• the object runs a method to process the data within a mirai inside the ExtendedTask
• an observe waits for the result of the ExtendedTask and performs some actions on completion

What's strange is that within repeated Shiny sessions I can create the same objects from the same data in the same order but only on some sessions will I get the error in the title: an ExtendedTask will conclude with an error instead of success but the mirai is in an unresolved state. The error is never consistent; if I run the above process on 10 files, some sessions none will return an error, sometimes a session might return 2 files as error; the files that result in an error are never necessarily the same.

It's my understanding that an error should never arise from an unresolved state in mirai.

The code is fairly complex and from a proprietary code base so I'm not able to share it unfortunately.

[shikokuchuo]

What does your ExtendedTask$new() call look like? It should be a function that returns a mirai. If the mirai is nested within another object then it won't be correctly handled by Shiny as an ExtendedTask.

[shikokuchuo]

The whole onFulfilled part of your promises::then() call is redundant as the promise value should never be unresolved. I'm curious - you are using the latest CRAN or dev versions of the mirai and nanonext packages i.e. at least nanonext 1.5.2 and mirai 2.2.0?

[James-G-Hill]

Hello, I agree that the onFulfilled part shouldn't be necessary but I've had to handle the unresolved values that come through. Without that they still occur. I originally used promises::catch but the unresolved values were slipping through.

Versions I can confirm this error occurs on:

• nanonext : 1.5.2
• mirai : 2.2.0

[shikokuchuo]

The only other non-standard thing I can see is getNamespace(golem::pkg_name()). Is it possible to test it so it doesn't have that? We can at least try to narrow it down.

[James-G-Hill]

I've also uploaded the code sample above to give you a better idea of what's going on in case the other parts might be relevant.

EDIT: seems my edit was lost; I'll try your suggestion first then re-edit again if that doesn't solve it.

[James-G-Hill]

@shikokuchuo Okay, I'll try your suggestion without the namespace soon. Might take a week or so because having to handle some other important work at the moment. I'll get back to you when I've had a chance.