QueryFailedError - Since Build Apps change 25th Feb

[smckenna]

Hi, i noticed that since the latest Build Apps 2025-02-25 release i am getting errors where the query on the build apps cloud visual function DB.  It looks like it is defualting to lowercase and returning with an error when i have camalcase as the feild ID.  I made no changes, but i can see that there was a change made in the change logs for build apps yesterday.  Are others experiencing this behaviour.

Steve

[smckenna]

I have done some more testing and notice this behaviour, i assume it might be linked to the decommissioning of system variables in the release notes, but not sure.

Prior to the release - i have created additional UUID fields in my files to support filtering conditions.  This worked when i filtered on UUID fields - this allowed my to filter as it seemed like Build Apps expected to filter on a UUIDs - so i created additional fields as UUIDs. This worked.


After the release:  Filtering now works on only the non-UUID fields the and the System UUID field, but not UUID fields that i have generated.  I also note that when i set up the additional UUID field in the DB i didnt mark it as required, so i notice there is a difference between the system UUID field and the additional UUIDs that i created. 

I can see that the release has caused a change in system behaviour, im not sure if that is by design with the decommissioning of the system variables, or if there has been an unintended impact.  I might need to re-design some of the back-end to get it working i think. 

Steve

[smckenna]

@Dan_Wroblewski , Hi Dan, just confirming a change in the Build Apps behaviour since the last release.  I just want to confirm if it is intentional or might be rolled back before i change my application.

The key change is that build apps is no longer able to filter on UUIDs that have been created over and above the system generated UUID.  Prior to the change I generated UUIDs for filtering of cloud visual function files, After the release the only fields that work via conditional filtering are the System generated UUID "ID" field, text and number fields.  It seems like the behaviour has switched from wanting a UUID to filter on, to now no longer supporting a UUID and enabling text and number fields instead.   I am hesitant to restructure my app to avoid UUIDs if this change will be rolled back. Appreciate any guidance.  Looks like its linked to yesterdays release.  I also tested creating a UUID and marked it as required (to mimic the system UUID) but this also fails.

Steve

[Dan_Wroblewski]

I am trying to find out more, and will post if I do.

When you say you created additional UUID, can you explain your use case? When you say UUID, I assume you mean 128-bit unique IDs. Where they UUIDs related to some other system, or created by you randomly for this DB.

And when you say sorting, I assume you mean the "Ordering" inside the "Get record collection" flow function?

And can you just show an example of what changed in terms of the casing?

[Dan_Wroblewski]

I just created a new VCF entity and used in inside a new project. I was able to sort by my own UUID field. Could it be if I had an older database I can't now sort by such a field but a new database is OK?

[smckenna]

Thanks for looking into this Dan, appreciated. Looks like Marie has the fix identified and  planned.  For project mgt app i have a file for project and a file for project items, when i create the project items i also reference the UUID of the project.  I then use the "get records" functionality and create a filter condition to reference the active project ID stored in an app varialbe. I can then display or pass a filtered set of records to an api.

[MarieDuffy]

Hi, 

Because of a recent change that was made, the database has an issue with UUID columns that are not lowercase. In the upcoming release we will have a fix to accomodate any custom UUID column names and the system generated UUID field. In the meantime, UUID searching/filtering is working for column names that are in lowercase and should not return an error. 

[smckenna]

Thanks for the quick response Marie, i can work around this - thanks.  I did some testing and confirm that if i create a lower case field "uuid", it works, if i create a field "testUuid" it will fail - both of these were tagged as not required.  I created a "testUuid" field yesterday which was tagged as required, and this works for some reason now, will keep to lowercase.

Steve

Steve

[MarieDuffy]

---

I created a "testUuid" field yesterday which was tagged as required, and this works for some reason now, will keep to lowercase.

---

Can you confirm this column "testUuid" which is working is of type UUID? 

[smckenna]

Hi i have two field both set as UUID type and both with an uppercase in them, with the difference being the one tagged as required will work, but the one tagged as not required will not work. The below is the one that works. 

Steve

[MarieDuffy]

Can you please include a screenshot of the field that you didn't mark as required? I have not been able to reproduce this case from my side 

[smckenna]

Hi Marie, there seems to be another change applied, to the product, this was working last week, but now when i run the "update record function", which references a UUID in an application variable to select the record and post an update to the record i get the following error "{"code":"requestFailed","status":404,"message":"Request failed with status code 404","rawError":"<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n<meta charset=\"utf-8\">\n<title>Error</title>\n</head>\n<body>\n<pre>Cannot POST /destinations_api/v2/destination/SAP-Build-Apps-Runtime/projects/04c5908a-10c8-484f-96ed-547792348fff/entity/PocSaPprojectsinitial</pre>\n</body>\n</html>\n"}"
@Dan_Wroblewski , @MarieDuffy 

I havent made any changes to the app, so it seems like another backend database change driving the error.  The error message is triggered, but the create record function is actually successful so i can see the update has written to the database succssfully. 

The logic flow now stops at the error message, but to work around it i now link the error message path to the next step, so it forces the next step to continue.  So i think the error message is triggering incorrectly for some reason, and the positive create record path is stopping incorrectly. 

[MarieDuffy]

Sorry about this, this is an unrelated issue that the team is aware of and the fix should be out for shortly. 

[smckenna]

Fantastic, fixed, appreciate the fast turn around. 

[Dan_Wroblewski]

Thanks for reporting this so quickly after the release. I reported it, and then luckily Marie and company found the issue. 😺