Server stucks when an API call promise resolves in a timer execution body

Hello everyone!
Since I can’t use any kind of context in the timer execution body, I decided to make an HTTP request to another service from a timer.
My timer looks like follows:

import 'bla-bla-lba' from 'path'
  name: 'Timer_name',
  frequency: {
    schedule: 'daily',
    repeat: { every: 1 },
  async execute() {
    await Backendless.UserService.loginAsGuest();
    const userId = Backendless.UserService.currentUser.objectId;
    await Backendless.UserService.assignRole(userId, UserRole.Scheduler);
    try {
      await Backendless.APIServices.invoke('myService', 'refreshAction');
    } catch (error) {
    await Backendless.UserService.logout();
    await Backendless.Data.of(User).remove(userId);

The issue reproduces when the timer starts invoking the API service. The server becomes irresponsible at all until the debugger is deattached.
Please notice, the issue doesn’t reproduce when the timer is deployed, the server stucks when I’m in the debug mode only.

Additional info may be helpful:

java.util.concurrent.CompletionException: java.lang.NullPointerException: Cannot invoke "java.util.concurrent.CompletionStage.whenComplete(java.util.function.BiConsumer)" because the return value of ", com.backendless.servercode.ExecutionType, boolean)" is null

As of now, we rewrote the code to use then chain syntax, but I’m afraid if the Java thread you allocate for the timer doesn’t complete the inner async logic (that doesn’t resolve by our code) before destroy itself. When we had added Promise.resolve(result) for the final promise returned by the chain, the server stucked again. So, the code in the timer is not awaiting now.

Thank you!

Hi @Boris_Velvetech ,

To clarify situation - both, timer and service, are hosted locally in debug mode?

Regards, Andriy

Hi @Andriy_Konoz,
That is correct. When both, timer and service are deployed to Backendless, everything works.
The issue reproduces in the debug mode only.

Thank you.

@Boris_Velvetech ,

Your current behavior is caused by fact that CodeRunner uses only 1 thread in debug mode locally and when you making a call to your custom service you block single thread which handles everything. I have created an internal ticket to discus this possibility to increase of amount of threads.

I would advice you to move that service to a different model and run it in a second instance of CodeRunner locally or to deploy it to your app.

Regards, Andriy

Hi @Boris_Velvetech

Sorry for the late response!
We just implemented debug-workers. You can see details in the PR:

It’s not on the prod yet, but it’s already available for testing. To install the version run the following command:

npm i backendless-coderunner@next -S


Hi @Boris_Velvetech,

In addition to the post above, I would like to add that the fix is already available in production. When you can test it on your side, we will look forward to your response.