Paralell API requests provides incorrect date fields
Issue: Random dates are provided for date fields, when simultaneous or parallel requests are made.
Steps to reproduce:
1. Take a view with more than 25000 records
2. Save the following file as test.sh, providing appropriate values for VIEW_ID and DOMAIN and ACCESSTOKEN
````
#!/bin/bash
rm $1
ACCESSTOKEN='Removed for security'
for (( i = 1; i < 4; i++ )); do
#statements
echo "https://[DOMAIN].s.xtrf.eu/home-api/browser?viewId=[VIEW_ID]&page=$i&q.task.quote.service=9&maxRows=1000&q.task.invoiceable=yes&q.startDate=from($2)"
curl -X 'GET' \
"https://[DOMAIN].s.xtrf.eu/home-api/browser?viewId=[VIEW_ID]&page=$i&q.task.quote.service=9&maxRows=1000&q.task.invoiceable=yes" \
-H 'accept: application/vnd.xtrf-v1+json;charset=UTF-8' \
-H "X-AUTH-ACCESS-TOKEN: $ACCESSTOKEN">>"$1_$i" &
done
wait
cat $1_*>$1
rm $1_*
````
3. From the terminal run,
./test.sh xtrfRequest1.jsonl 168048709288
4. From the terminal run again,
./test.sh xtrfRequest2.jsonl 168048709288
5. Chech the diff of both files.
Expected Result:
Both xtrfRequest1.jsonl and xtrfRequest2.jsonl are equal and have the same records with the same fields.
Actual result:
Some records(Odds: 4 records in 3000) have their date fields modified to random dates. For eg, xtrfRequest1.jsonl's 1 record maylook like
"columns" : [ "268512", "28.02.2023 16:18 GMT", "Service", , "Closed" ]
and the same record in xtrfRequest2.jsonl may look like
"columns" : [ "268512", "27.02.2022 21:15 BST", "Service", , "Closed" ]
Notes:
- Only Date fields are affected
- Only some records are affected and the affected records are random.
- The dates seem to be put from another record, but it maybe completely random as well.
Customer support service by UserEcho
Hello, if you are experiencing any issues, please report them to our Help Desk, and we will be able to process your questions :)
I'm tried to register on the helpdesk. Could you accept my application?
The same happened when transferring information from a view into the Google sheet add-on.
It's clearly a issue with "date fields" in their backend. I was able to clearly demonstrate the issue with the code above. Just was hoping to get any updates on the issue.