different results in debug and release modes

different results in debug and release modes

I've come across an issue when developing my app - when I test the app in release mode, it doesn't work. But when I try to find out why in debug mode and step over the code I get the proper results on screen. 

Click a row in table records -> update the row based on result of a calculation (flag) -> display row detail based on updated flag value.

in debug mode this works fine, in release mode i don't get the updated flag(null). (seems to me the action to update the flag is not even called). 
Is it possible the action in release mode will not be called and same context in debug mode behaves differently?
Any ideas?
I've personally never encountered behaviour being different between production and non-production environments, so I assume there's something else going on.
Please see attached oml.

User actions and what should be done : In accounts tab, click account with far right ID ==0 , ID is being assigned, and on account details screen at the bottom you should get table records form filled in with some upload widgets. 

This works fine if you put breakpoint somewhere in the process, say account details preparation (END shape). 
however, if you run this with no breakpoint or in release mode, you always get ID=0, therefore the table in details is empty. 

i hope i explained it well. I'm new to this and I'm really stuck. Help much appreciated.
I don't say it is a bug or something in debugger, i think it has something to do with table locks?
Table locks will not be an issue, by default all queries are run with "read uncommited".

Are you sure that you are passing in a valid AccountId? Are you sure that this record exists in the environment you are testing in?

No, I am not sure, because I can't debug it...obviously. It works fine when it meets breakpoint, but it does not, with no breakpoint on the process path. 

The question is - Why it works with breakpoints but does not without?
Tomas, I've never encountered this behaviour, and find it highly unlikely that it is caused by not debugging. I can't think of a single reason why that would cause the application to work, but not without debugging, on the same environment.
I have seen some different behavior around *multi tenant data* when comparing run-time vs. "Test Query" but I have also never seen a difference between "Debug" and "Release".

Are you *positive* that you are running in the same envronment using the same DB?

Kilian : I've attached the .oml in previous post ... so maybe you can give it a shot and prove me wrong (hopefully).

J.Ja. : Well, i run it on outsystems cloud...i don't really have an idea what's happening there, so... (if that can affect my app)

Tomas: unfortunately I don't have acces to a v9 platform currently.
Hi Tomas

I didn't quite get how to do the operation that should fail. Can you try to explain it a bit more step-by-step?


Hi Tomas,

I gave it a go in a P9 environment and what it seems to me is that the aggregate GetORtablesByIndiciaID is not returning anything and so the TableRecords on the detail will have no rows and won't show any upload widgets.

I tried with and without debug mode with the same outcome.

You should validate if you have the necessary values in the environment on which you are trying to test and also if you'd like to demystify the debug/non debug problem what you can do is use the System Action Audit and log some information on your espace (put on the different branches, after outputs, etc) and test in non debug mode.

Than check your management's console General log to see what's really happening on non debug mode.

Hope this helps,

quick question, what stack/db are you using?

there *may* be some unintenional differences 
Thanks to all of you ! 

Guilherme : thank you ! didn't know about the management console / audit stuff, this really helped me out to debug it without breakpoints....the bug was this : in AssignIndicia action, i have input parameter AccountID, then GetAccountByID Aggregate, and then i'm assigning this account to local variable. here comes the bug : in this assign i had : Account = 
it was supposed to be Account = GetAccountById.List.Current.Account
Therefore in my local variable i had this 'current' object and i couldn't get Address, Birth etc from there... But I still could get Account Name ....

Can you explain this to me? 

still not sure, why this worked fine with breakpoint in debug mode, but not in 'release' ???
Hi Tomas,
Because your aggregate only has one source GetAccountById.List.Current and GetAccountById.List.Current.Account and so they have the same value.

I've looked again into your action and what seems to be the problem is that the Account variable is of type Account and the UpdateAcc is a record of type account. And so might be this that was causing the confunsion but I'll let someone with more knowledge on the new datatypes to try and explain (without speculation because that I could do :))

Anyway why are you using so many variables to this operation?

Couldn't you just use the output from the aggregate, assign the indicia values and that use that object on the UpdateAccount action?

obviously GetAccountById.List.Current and GetAccountById.List.Current.Account is not same value/object, 
what i dont understand is why from "Current" object I can get "Name" attribute, but not "Address" . 

From what i understand - reason why this didn't throw error in truechange : inheritance. "Account" extends "Current" ...so yes, it was correct data type wise. Though I think I shouldn't be able to get Name attribute from Current...

It would be perfectly fine if I couldn't get any entity attributes from the "Current"
Correct me if I'm wrong.
Tomas Pritrsky wrote:
obviously GetAccountById.List.Current and GetAccountById.List.Current.Account is not same value/object, 
Correct me if I'm wrong.
You are wrong. In case the output of a query (I don't really care for the aggregate stuff, it's just a badly redisigned if somewhat slightly more powerful simple query) is a record list of a single record or structure, QueryName.List.Current is exactly equal to QueryName.List.Current.OutputRecordType. So even though I understand your confusion, you stand hereby corrected (sorry, you asked for it, litterally :)). It has also nothing to do with inheritance, or extending a type or whatever; the OutSystems Platform is not object oriented.
what i dont understand is why from "Current" object I can get "Name" attribute, but not "Address"
I really don't know what you mean here by "get from". Perhaps you can explain what you did?

please understand 'get from' as 'return value' (sorry for my english),
example :
Current.Adress returns "" (null, empty string, whatever),
Current.Account.Adress returns "308 Negra Arroyo Lane"
talking about the same Account.

Therefore QueryName.List.Current is not exactly the same as QueryName.List.Current.OutputRecordType ?
Thanks for the correction, object orientation of Outsystems (it is not a good marketing point, like, "OH HEY, YOU CAN DRAG AND DROP EXCEL SHEET TO CREATE AN ENTITY AND UI TABLE TO EDIT ROWS!!!" :D )
Hi Tomas,

There is some kind of confusion here. Like Kilian said QueryName.List.Current is exactly the same as QueryName.List.Current.OutputRecordType.

And by the way get the attribute directly from the list current its not possible as you can see:

Right now this thread is not going in a productive/helpful direction.

I'm not excluding the possibility of a bug because as the OutSystems platform is also a piece of software software and bugs do happen (specially in the intial stages after new releases :)) but without understanding clearly whats affecting you it's dificult to be more helpful.

Can you post some more details about the specific error and the Audits that proved you that in debug works but in "release" doesn't? Perhaps with a couple of screenshots so it may be clear to all of us?

I made this simple example of the issue we are talking about (QueryName.List.Current vs QueryName.List.Current.OutputRecordType). 
Preparation : 
Actual data : 

Room_Current.Room is empty and this is OK.
Room_Current is empty and according to QueryName.List.Current is exactly equal to QueryName.List.Current.OutputRecordType, 
this is NOT OK.

Added assign which references Current.Room : 

I'd expect the Room_Current would be the same (empty), BUT IT IS NOT : 

Debug mode : 

UI : 

I hope I made myself clear ...Can anyone explain this to me? 

Is "QueryName.List.Current is exactly equal to QueryName.List.Current.OutputRecordType"  true? Doesn't seem so to me.
Debugger involved causes different results???

Could you post an eSpace with this minimal example?
Kilian Hekhuis wrote:
Could you post an eSpace with this minimal example?
 please see edited post.
The eSpace you provided lacks an assignment in the Preparation of GetRooms.List.Current.Room to Room_Current_Room. If you add that, you will see that both contain the same data, and both display as expected.
Kilian Hekhuis wrote:
The eSpace you provided lacks an assignment in the Preparation of GetRooms.List.Current.Room to Room_Current_Room. If you add that, you will see that both contain the same data, and both display as expected.
Yes, and that is perfectly fine.
But the thing is, when you add this assignment ( Room_Current_Room = GetRooms.List.Current.Room ), also the data in Room_Current changes (it is not empty anymore). This Room_Current is empty without the added assignment on release. However, Room_Current is not empty with debug + breakpoint. 

 Clearly you can see the debug and release do not show same results. Did I miss anything here?
Tomas Pritrsky wrote:
But the thing is, when you add this assignment ( Room_Current_Room = GetRooms.List.Current.Room ), also the data in Room_Current changes (it is not empty anymore). 
I can't reproduce that, and that's good, because that really shouldn't happen. Room_Current_Room and Room_Current are records, and assigning the one definitely shouldn't effect assigning the other! 
I'm on v9.0.0.6  ...maybe thats why?

Can anyone else confirm this is actually a bug on version
(Not like I so want to find bugs on Outsystems, but I can't explain this to myself any other way!)
I installed as well, specifically for this problem, so that can't be it. Could you upload the version of the BugProof eSpace which has the two assigns and manifests the problem directly (so it can't be I'm doing something different)?
file attached^ ... just added the assignment.
thank for your help, really appreciate it!
Hi Tomas,

Thanks for your effort to get a minimal example. This is indeed a bug in, which happens whenever you assign an expression of type "A Record" to a variable with data type "A", where "A" is an Entity or a Structure. The current workaround is, like you discovered, accessing the attribute to get an assignment from "A" to "A".

You get the expected result when using the debugger, because it forces the Aggregate to fetch all attributes to help in the debugging process.

Paulo Ferreira
Thanks Paulo,
Looking forward to next version ! :)