Backendless Version (3.x / 6.x, Online / Managed / Pro )
Online
Client SDK (REST / Android / Objective-C / Swift / JS )
N/A
Application ID
AE4235E1-DBB7-C6F0-FF4A-E0378B0B2B00
Expected Behavior
Please describe the expected behavior of the issue, starting from the first action.
- Make an API request to the service in question with the profileId parameter.
- Get a valid response.
Actual Behavior
Please provide a description of what actually happens, working from the same starting point.
Be descriptive: “it doesn’t work” does not describe what the behavior actually is – instead, say “the request returns a 400 error with message XXX”. Copy and paste your logs, and include any URLs.
- Make an API request to the service in question with the profileId parameter.
- Get an error - profileId is not defined
Reproducible Test Case
I’ll include a screenshot of the codeless logic where the error seems to be occurring. “profileId” is a method parameter in the request body. I have not defined any “profileId” variable in the codeless logic. I have confirmed that I am indeed providing it in the requests in question. I am also not the only one having this issue with the API.
To my knowledge no one has made changes to this codeless service, it just started exhibiting this behavior out of the blue. What could cause this to start happening?
Have you tried adding a print
block to log the profileId
value? I am curious what it will show.
Additionally, is it a GET
or POST/PUT
request? Do you pass the argument in the body or in the URL?
So that was very strange…when I added a logging statement before the Get Object block and redeployed, that error went away…I ran into some other errors that needed fixing, but I have no idea why that would fix the issue. I have since removed the logging statement and the problem hasn’t shown back up.
This is odd. It tells me the service was not fully deployed and didn’t have the changes. Let us know if the problem reappears.
Regards,
Mark
Have you had any bug reports of changes being reverted in codeless logic? That is my suspicion here, because it looks like the logic was changed back to a previous iteration. None of us have touched this logic in weeks to my knowledge - is it possible for you to see a server-side changelog? From what I understand the changelog in the UI only shows changes made in the browser, not those server side.
I am not aware of the issue. The log file (in the `/logging directory) should have entries for every deployment. There may be some clues there.
Additionally, if it helps, here’s a list of all the deployments from the past few days:
Ok - it looks like there were some alterations made to the code my someone else, but they were intended. However the initial issue was quite odd and a little concerning, I couldn’t see any reason why that would happen.
If someone else had the logic on their screen without your changes, then it would be deployed as-is (i.e. without your changes).
Mark,
We are now seeing the same problem on another method in the same API (updateTemplate in the templates API). Can you have someone take a look? We haven’t touched it so that someone can verify the bug and maybe figure out what is going on.
It’s a different parameter (class_length) but same issue, the error seems to be throwing when we try to reference a method parameter (even if that parameter is correctly sent in the request body).
Hi Christopher,
Could you please provide a sample payload with values for the method so we can reproduce the problem?
{
"class_length": 0,
"cost": 0,
"description": "string",
"location": {},
"pricing": "string",
"rrule": "string",
"title": "string",
"spots": 0,
"packages": [
{}
],
"from_date": 0,
"pack_required": false
}
Hi @Christopher_Manzi1
Thanks for your report!
We were able to reproduce the issue BKNDLSS-31953 and we are going to fix the case in the next release.
As a temp workaround, I can provide you with steps that help you to move on:
- open the Codeless designer
- select the method
- move any root block just to recompose code, the method has to be marked with the green color (has local changes)
- deploy the service
Regards, Vlad
Does this discussion imply that something was recently updated in Backendless which broke some working API services? Or it’s the result of something we did or didn’t do in the logic for the API service?
Yes, we recently released an improvement for API Services arguments, but suddenly we get a rare side effect.
The issue has been already fixed and it’s in the testing stage.
Regards,
Vlad
Hi there @Alex_Klein,
We updated cloud servers with a fix for the issue we discussed above. Could you kindly let us know whether fix works for you well?
Regards,
Marina
can’t really confirm because we have not had the issue re-appear… but we believe you