Closed matbmoser closed 1 month ago
A solution to this bug should be found, or it should be included in known knowns at the release 4.0.0 notes.
This happens when data contains only 0's
immediately after decimal point like20.0
or 20.0x
(x: 0). During the tests, it was discovered the only case where the data integrity is not maintained, in all other cases, it works as expected.
@saudkhan116 and I have solved the problem:
1º - Set response type from backend /api/data
api call to "text"
2º - Parse the text response with Lossless-Json library (which maintains the integrity of the payload)
3º - Get "Aspect" field from the response and stringify it with the library method, then store it to a variable
4º - Parse the response with the "default" JSON JS Method
5º - When the "check verification" button is clicked the "string" stored in the variable (the raw response), will be sent to the verification API, maintaining its integrity. The content shown in the frontend, its parsed and will "only" not display the ".0" part.
It will be included in the RC2 release
Current Behavior
When retrieving data from the digital twin registry and then afterwards calling the EDC proxy, the backend serves the data correctly to the frontend. However when the frontend parses the json data it changes the data integrity of integers that contain a "float" expression.
Example:
If a data in the payload comes from the backend like this (the way it was registered):
The frontend will parse the request body like this:
Changing the data integrity, making it impossible to be verified with the verification add-on.
Expected Behavior
The data should maintain its integrity, and not be changed just because the parser removes the .0 from the integers for "optimization" purposes.
Steps To Reproduce
Retrieve an aspect that has a "xx.0" decimal case. And try to verify it with the frontend application.