ASP.NET: Server Actions maps incorrect data sometimes when calling an API

Wappler General Bugs
#1

Server Model is ASP. DB is MySQL. Hosted on AWS.
Wappler v2.9.1

Server Action Setup

API Call Body:
{
“A”: “{{$_GET.a}}”,
“B”: “{{$_GET.b}}”,
“C”: “{{$_GET.c}}”,
“D”: “{{$_GET.d}}”,
“E”: “0”,
“F”: “{{$_GET.f}}”
}

API Query Params:
“wf”: “ab_Test”

API Headers:
“headers”: {
“X-Tok”: “{{$_SESSION.tok}}”,
“X-Sou”: “web”,
“X-A”: “{{$_GET.a}}”
}

GET URL called from browser (server connect):
https://name.domain/dmxConnect/api/App/updateAction.aspx?a=558855&b=0456123789&c=blabla%40hotmail.com&d=&f=8877

This GET called the Server Action with following header:
{
“A”: null,
“B”: “0456123789”,
“C”: “blabla@hotmail.com”,
“D”: “”,
“E”: “0”,
“F”: “8877”,
“RequestDetail”: {
“Accept”: “application/json”,
“Accept-Encoding”: “gzip”,
“Expect”: “100-continue”,
“Host”: “name.domain”,
“User-Agent”: “ServerConnect/1.0”,
“X-Tok”: “45d64874-6e52-45df-52ce-d948fd23ecb1”,
“X-Sou”: “web”,
“X-A”: “558855”,
“wf”: “ab_Test”
}
}
incoming API call body is logged by us in the DB.

PROBLEM:
$_GET.a is the param in both body and in the header.
but it seems that Wappler replaced the value in header properly but not in the body.
in another variation of similar problem, the value passedfrom website GET URL was “1” but in the API call, server action replaced it with “.” (a full stop)

We see that these problems happen about once every 10000 server action calls.
These have happened multiple times to us. Our scale has grown enough now for us to be worried!
please let us know if you need some more info on this to resolve. thank you.

key and values names are masked for privacy reasons. the structure is untouched.

#2

bump, ICYMI!

#3

bump again!!!

#4

Does this mean it doesn’t happen each time, just about once every 10000 calls? This will be very difficult to resolve when there is no good way to reproduce this.

#5

yes, it does not happen every time (thank fully).
it is rare indeed.
but given our volumes - Server Actions are run many-10000s times a day - which is why this is a serious problem.
we’re not even sure if Wappler is causing it - we just suspect that it is.

#6

we’re facing this problem still on a daily basis.

i am sure Wappler team would not like that their product breaks down for high-concurrency large scale applications!

requesting revert - how we can work together to resolve this issue!!!

#7

Hi, guys this is a serious issue. a show stopped @George, have u heard of similar complaints?

#8

No we don’t have any other complains - if you have a clear reproduction case, please post a new bug report topic with all the details.

#9

there is no clear way to reproduce this.
as i had mentioned earlier, we have 10000s of Server Action calls everyday - this comes from 100s of clients logging into our website.
of those a couple fail with this problem.
we have about 30 SA in this project and the problems are spread out in different SA, not just a single one.
all the SA are API calls, none are using DB connections.

i guess to be able to reproduce this, will have to replicate our setup of having all SA as API calls and invoke 10000s SA in a day. these are the specific points we can give - under which we are facing this ongoing problem!!!

#10

Maybe you can build some kind of failsafe? Add the number of records returned, next to the records and check if it matches.
When it doesn’t log an error with the user parameters and run the query again.

#11

thanks for the suggestion.
unfortunately, each API is not doing a simple CRUD - it is a much complex workflow with each API that is performed based on many conditions.

also, calling the API again from within the SA might yield same issue since the params are changed from when it is passed by the browser to server and then on server how Wappler calls the API.
the value in header and in body of the API call also varies sometimes when the mapper is the same string.

#12

if it helps, we can explain the issue a bit more clearly over remote by showing the system step by step. but there isn’t a defined way to replicate this issue as it is very random but still consistent.

#13

Well the Wappler ASP.NET code gets executed each time and $_GET parameters are executed each time the same.

It is impossible even on high load to get different execution.

Maybe the problem is somewhere else? Like not passing the right attributes or something else in the underlying MySQL driver for .net?

Maybe try a to mockup a separate showcase that we can run and see the problem as well?

Also we are having a summer break for a few weeks now so response might be slower than normal.

#14