Has anything user related changed overnight?

I have apps that were working yesterday unable to login today, I’m getting "No current user found, code = 1400 response in debug. Again these apps have been functioning, were functioning yesterday as well no changes have been made on our end and are not working today. I’ve been troubleshooting on my end to no avail.

Hi @Matt_Olson

Please provide us with the steps so that we can reproduce the problem on our side. Are you talking about the user login to the application?

Regards,
Marina

I’m not sure how to go about reproducing it without sharing our source code with you which is probably not appropriate. I’ll work on creating something that uses our login method and point it to a clone of our app on backendless.

Talking about the user logging into the app from their mobile device. In backendless the user login is functional.

There appears to be a difference in behavior between Backendless Java cloud code that is deployed and cloud code that is being debugged through the “CodeRunner” construct.

When making the following two function calls within our Java cloud code within an endpoint requested by our mobile application with a valid logged-in-user token, if the cloud code is “deployed” and running solely in Backendless, neither is returning the expected result. The value returned by “loggedInUser()” is “null” and the value returned by “isValidLogin()” is “false”.

If, however, the cloud code handling the request from the mobile application is currently running through the “CodeRunner” debugging structure, both calls properly return their expected values - the valid logged in user ID and “true”, respectively.

String userId = Backendless.UserService.loggedInUser();
boolean isValidLogin = Backendless.UserService.isValidLogin();

Everything was working as expected with the deployed cloud code prior to some time on 05/22/2023, but now no deployed cloud code is properly processing the requesting user context. Redeployment of the cloud code has not alleviated the issue.

In both the “CodeRunner” context cloud code and the deployed cloud code, the following functions are returning the same - and seemingly accurate - values, including the same user token header.

InvocationContext.getHttpHeaders();
InvocationContext.getUserId();
InvocationContext.getAppId();

Hello @Mark_Moline, @Matt_Olson,

Which version of Java SDK do you use?
Please update to the latest one:

Also, a new patch-release is expected today with a new Coderunner version.
Unfortunately we cannot reproduce this issue right now without a step by step instructions with current and expected behaviour (e.g. a simple code sample that reproduces the issue, not the whole source code).

Regards,
Olha

Again - everything was working as of the evening of 05/21/2023 with this code and our mobile application code unchanged and it had been stable for months.

Here is a simplified example of my cloud code:

MobileService.java

public class MobileService implements IBackendlessService {
    public BackendlessUser getMyUser() {
            BackendlessUser user = HelperService.GetCurrentUser();
    
            return user;
    }
}

HelperService.java

public static BackendlessUser GetCurrentUser() {
        BackendlessUser user = null;

        String userId = Backendless.UserService.loggedInUser();
        boolean isValidLogin = Backendless.UserService.isValidLogin();
        
        //When running in debug through CodeRunner.sh this conditional is executed because userId is found and isValidLogin is true
        //When executed in deployed Backendless this is not executed because userId is null and isValid Login is false
        if(userId != null && isValidLogin) {
            user = Backendless.UserService.findById(userId);
        }

        if(user == null) {
            String errorMessage = "No current user found for ID";
            String errorCode = "1400";
            int httpStatusCode = 400;
            BackendlessException e = new BackendlessException(errorCode, errorMessage, httpStatusCode);
            throw e;
        }

        return user;
    }

CodeRunner output with version info:

02:55:20.946 [INFO] c.b.c.CommandLineProcessor |main| CodeRunner(tm) Backendless Debugging Utility
02:55:20.946 [INFO] c.b.c.CommandLineProcessor |main| Copyright(C) 2023 Backendless Corp. All rights reserved.
02:55:20.947 [INFO] c.b.c.CommandLineProcessor |main| Build date: 2022-08-01T07:48:01Z
Version: 6.6.3
Build id: 227843
VCS revision: 97430affd986adae12c11464d87830eec79d1c8f

If it is possible that a core Backendless code/configuration change occurred that has rendered the SDK version(s) that I am using non-functional for running or communicating with deployed Backendless cloud code, is there a communication channel or broadcast that I could see or subscribe to in order to be informed when such a change is being made?

We are already investigating this issue. It has the highest priority and all be fixed ASAP.

Hi. Please try to download the newest version of our CodeRunner and copy your code there.

I am now getting the following error from a cloud code API request while debugging through the new CodeRunner:

14:42:38.038 [ERROR] c.b.c.r.t.ServiceInvocationTask |JavaWorkerPool_pool-thread-1| Error when set InvocationContext
java.lang.IllegalAccessException: class com.backendless.coderunner.runtime.task.ServiceInvocationTask cannot access a member of class com.backendless.BLHeadersManager with modifiers "public"
        at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
        at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
        at java.base/java.lang.reflect.Method.invoke(Method.java:560)
        at com.backendless.coderunner.runtime.task.ServiceInvocationTask.createInvocationContext(ServiceInvocationTask.java:226)
        at com.backendless.coderunner.runtime.task.ServiceInvocationTask.runImpl(ServiceInvocationTask.java:128)
        at com.backendless.coderunner.runtime.executor.ExtendedRunnable.run(ExtendedRunnable.java:42)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
        at java.base/java.lang.Thread.run(Thread.java:833)

I had to upgrade to Java 17 in order to run the new CodeRunner version, which I obtained by downloading one of the project templates from a Backendless App.

14:42:16.139 [INFO] c.b.c.CodeRunnerLoader |main| JDK from "JAVA_HOME" - /usr/lib/jvm/java-17-openjdk-amd64
14:42:16.221 [INFO] c.b.c.CommandLineProcessor |main| CodeRunner(tm) Backendless Debugging Utility
14:42:16.222 [INFO] c.b.c.CommandLineProcessor |main| Copyright(C) 2023 Backendless Corp. All rights reserved.
14:42:16.223 [INFO] c.b.c.CommandLineProcessor |main| Build date: 2023-05-24T09:22:19Z
Version: 7.0.1.5
Build id: 241586
VCS revision: 02b11e968bd18df51f1dec5c733507e3aff4b145

Cloud code requests continue to fail when actually deployed (non-debug).

I have the following “lib” structure for my cloud code from the newly downloaded project template:

I should note, as well, that our mobile application structure relies on cloud code requests during its user initialization and so all of our apps are non-functional because of this problem.

Would it be possible to roll back the changes that were deployed by Backendless on 05/22/2022 or between 05/21/2022 and 05/22/2022 for our Backendless Cloud apps in order to restore our mobile application functionality?

Can you send your code to a private message?

The code we already referenced in the thread is what is failing.

The code that @Mark_Moline made reference to earlier is what is failing. Do you need something more specific?

Hi @Matt_Olson ,
I saw your message in the pm, it should be enough for local debugging, thank you.

I recreated your code with the new CodeRunner version but didn’t get any errors.

public class MobileService implements IBackendlessService
{

    static final String BACKENDLESS_HOST = "https://api.backendless.com";
    static final String APP_ID = "xxxxxxxxxx";
    static final String API_KEY = "xxxxxxxxxx";


  private static final MobileService ourInstance = new MobileService();
  public static MobileService getInstance()
  {
    return ourInstance;
  }
  public BackendlessUser getMyUser() {
    return HelperService.GetCurrentUser();
  }

  public static void initApplication()
  {
    Backendless.setUrl( MobileService.BACKENDLESS_HOST );
    // if you invoke this sample inside of android application, you should use overloaded "initApp" with "context" argument
    Backendless.initApp( MobileService.APP_ID, MobileService.API_KEY );
  }

  public BackendlessUser loginAnon() {
    return Backendless.UserService.loginAsGuest(true);
  }
}

public class InvocationExample
{
    public static void main( String[] args )
    {
        MobileService.initApplication();
        MobileService service = MobileService.getInstance();
        service.loginAnon();
        BackendlessUser getLogUser = service.getMyUser();
        System.out.println(getLogUser);
    }
}

So where does this leave us, this code worked up until the CodeRunner changes and it is now not working for us in our environment. I’m happy it is working, I would expect it to, I just need it working from what we have built as it did before whatever changes where made last weekend or sometime on Monday.

As you have stated our code works, and it did before for us too, so what is different between how you’re running it and how we are running it? Maybe an update hasn’t made it to our database yet? I’m grasping at straws here and need to get this resolved. This will be a full week that we have not been functional soon.

Is this example actually being run as Backendless cloud code? If so what’s the purpose of the main method, initApplication and other additional functions?

I have gone through the following troubleshooting steps this morning and am still observing the same conditions and errors previously described in this thread:

  1. I stripped down the entirety of my cloud code to just the getMyUser endpoint and its associated helper function which have both been posted in this thread.
  2. I tested this minified cloud code in debug through CodeRunner Version: 6.6.3 with Java 15 and that is the only running state through which the code works and properly finds and returns the currently logged in user.
  3. I tested this minified cloud code in its deployed state after having been deployed using CodeRunner Version: 6.6.3 with Java 15 and the process fails finding “null” for userId and “false” for isValidLogin.
  4. I tested this minified cloud code in debug through CodeRunner Version: 7.0.1.5 with OpenJDK 17 and the Backendless Java SDK version 7.0.2, both of which were downloaded through a project template from our Backendless App web interface, and the process fails finding “null” for userId and “false” for isValidLogin.
  5. I tested this minified cloud code in its deployed state after having been deployed using CodeRunner Version: 7.0.1.5 with OpenJDK 17 and the Backendless Java SDK version 7.0.2 and the process fails finding “null” for userId and “false” for isValidLogin.

I will repeat again that the entirety of my cloud code worked prior to whatever Backendless changes were dpeloyed ~05/22/2023, but it and this completely minified example now fail to work in any condition other than old CodeRunner in debug mode.

I’m not sure what more I can give you in order to aid with solving this problem. I have provided versions of everything that I can think of, exact code, debugging output. If there’s something else that I can provide or do that will lead to a resolution of this issue please let me know because I’m not thinking of it. I have tested with both our previously functional mobile application and through the Backendless App web interface for testing cloud code api requests.

Our relevant application ID where I have deployed the minified example with just the getMyUser endpoint is: D42DAAD0-460A-4D81-8C17-8A8EA5DCE101

I think we are at a point where rolling back changes made on 05/22/2023 is pertinent before continuing to try to identify whatever problem it created.

I’ve managed to reproduce the problem and localize it.
We’re working on it. I guess the fix will be tomorrow (will prepare the patch release).

1 Like

The problem was fixed and we are preparing the new build.