Thanks. I can reproduce it from the client side. But when I do the same on my Application I can not reproduce it. Could you please attach your business logic project that we can use to reproduce the issue? If there is some sensitive data you can send us it as message to the staff like described in the topic If you are a customer with Managed or Pro installation and send the link to the message in this topic
There were some changes about a month ago that may break the backward compatibility, for existing applications. So it may cause the issue you have. And unfortunately, we are not able to revert the changes. So the only way you can fix it is to migrate to a new project. We are really sorry for the inconvenience.
You introduced breaking changes without a warning and transition period
You didn’t communicate this to uses even post-factum
This is unacceptable! Not that I’m surprised given it’s far from the first time something like this happens…
And on top of that prices are increasing X-fold! Migration is imminent, indeed!
When I tried to debug the code from the project you sent me it also fails with the following exception:
Jun 13, 2023 2:41:38 PM com.backendless.coderunner.runtime.task.EventInvocationTask
SEVERE: Can’t prepare HeadersManager class.
java.lang.ClassNotFoundException: com.backendless.HeadersManager$HeadersEnum
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
at com.backendless.coderunner.runtime.task.EventInvocationTask.(EventInvocationTask.java:53)
at com.backendless.coderunner.runtime.CodeExecutor.invokeEvent(CodeExecutor.java:67)
at com.backendless.coderunner.processor.MessageDispatcher.onMessageReceived(MessageDispatcher.java:46)
at com.backendless.coderunner.processor.AbstractMessageProcessor.run(AbstractMessageProcessor.java:90)
[WEBORB ERROR, Thread-41, 06:13:23 02:41:38] unable to find matching server-side type for SignalsTest
The issue with SEVERE: Can’t prepare HeadersManager class. goes from another part of SDK, it should not impact your code. We are working on the issue with the header manager.
Well, I don’t know what should and should not impact my code but in the client app I still get the following fault when the project you sent me is deployed and enabled:
BackendlessFault{ code: ‘0’, message: ‘InvocationTask[ appId:BDCD56B9-351A-E067-FFA4-9EA9CF2F4000 ]\n Exception: java.lang.NullPointerException: Cannot invoke “java.lang.reflect.Method.invoke(Object, Object)” because “this.addHeader” is null\n\tat com.backendless.coderunner.runtime.task.EventInvocationTask.runImpl(EventInvocationTask.java:108)\n\tat com.backendless.coderunner.runtime.executor.ExtendedRunnable.run(ExtendedRunnable.java:42)\n\tat java.base/java.lang.Thread.run(Thread.java:833)\n’, detail: ‘InvocationTask[ appId:BDCD56B9-351A-E067-FFA4-9EA9CF2F4000 ]\n Exception: java.lang.NullPointerException: Cannot invoke “java.lang.reflect.Method.invoke(Object, Object)” because “this.addHeader” is null\n\tat com.backendless.coderunner.runtime.task.EventInvocationTask.runImpl(EventInvocationTask.java:108)\n\tat com.backendless.coderunner.runtime.executor.ExtendedRunnable.run(ExtendedRunnable.java:42)\n\tat java.base/java.lang.Thread.run(Thread.java:833)\n’, extendedData: ‘{}’ }
When I disable the event handler, call succeeds without executing the handler logic (as expected).
I can not reproduce the issue you have shown, I got the following:
BackendlessFault{ code: '1012', message: 'User has no permission to update entity 'SignalsTest'.', detail: 'User has no permission to update entity 'SignalsTest'.', extendedData: '{}' }
I have deployed the project I have sent you, could you please try to execute client with current deployed code, does it works?
No, it doesn’t! It fails with the aforementioned exception. In your case it just fails earlier for a different reason - because you are running it as an anonymous user. I guess if you are modifying my production app’s cloud code, you can also create a temporary use and try with it. BTW, I would also expect that you have logs of such exceptions in your code…
@milen-marinov ok now I was able to reproduce the issue, and on an isolated environment. I have increased the priority for the task to BLOCKER. Ingeneer is already working on it, we will let you know any news as soon as it is possible.