REST 2.0 Asset search not returning expected values consistently

Hello and thanks in advance for any help. I am trying to use the REST 2.0 interface to query RT for an Asset’s ID. The response I get has been inconsistent for the same query. I was wondering if anyone else is having this issue. I am using CURL to test my query and have followed the documentation. I have tried this on Ubuntu, RHEL and Windows 10 with the similar results. Any hints or help would be appreciated.
We are using RT 4.4.2 currently

Here is the query
curl -si
-H “Authorization: Token #####”
https://rt2.X.X/REST/2.0/assets
-X POST --data-binary ’
[
{ “field”: “Name”,
“operator”: “LIKE”,
“value”: “Test Asset” }
]’

When it works (or what I consider as working) it returns the following
{
“count” : 1,
“page” : 1,
“per_page” : 20,
“total” : 1,
“items” : [
{
“id” : “42”,
“type” : “asset”,
“_url” : “https://rt2.X.X/REST/2.0/asset/42
}
]
}

When it fails (again as I define fail) for the exact same query, it returns no items
HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx/1.12.2
Server: nginx/1.12.2
< Date: Wed, 27 Feb 2019 16:31:22 GMT
Date: Wed, 27 Feb 2019 16:31:22 GMT
< Content-Type: application/json; charset=“utf-8”
Content-Type: application/json; charset=“utf-8”
< Content-Length: 87
Content-Length: 87
< Connection: keep-alive
Connection: keep-alive

<
{
“count” : 0,
“page” : 1,
“per_page” : 20,
“total” : 0,
“items” : []
}

  • Connection #0 to host rt2.X.X left intact

Thanks for taking a look and providing any assistance

Hey,

Are you sending the same query? Anything in the server logs?

Do you have the same inconsistent results when doing other searches on other fields?

What if you GET a specific asset instead of doing a search?

The query was the exact same. I created an executable bash file and just ran it two times in a row. Unfortunately, I do not run the service and do not have access to the logs, but did request that the admins for the service take a look. It is a low priority for them and will take a while.

The GET is very different. I need a query and POST is the only option for this. If I run a GET and provide the ID# of the asset I get all of the values, but that is not what I am trying to do. I need to be able to use the Name attribute to look up the ID so that I can automate some functions that update or create values in RT. We are currently on 4.4.2 and an upgrade may address the inconsistency.

No errors are occurring. The server logs don’t show any information other than a successful connection. The admin upgraded the REST2 modules from 1.03 to 1.07 and we tried again without success. We suspect that either a cashed result buffer is being wiped or the input data in the query is being horked by something. There is no pattern to the success vs failures. It fails more than it succeeds.

I tried the query on the “Name” field and the “id” fields and had the same results. Both of these are RT provided fields so no issue with Custom Fields or hidden characters. The fact that it appears to randomly succeed is the strange part.

As a data point for you, I’ve tried a similar query (looking for assets in our test 4.4.4 version of RT that contain the word “Garry”, of which there should be two matches, and I seem to get consistent results.

I wonder if the Nginx server is doing some caching? One sneaky way to check might be to append something to the URL that RT will ignore but which is different each time. Something like this (assuming you have openSSL installed to generate the random number):

#!/bin/bash                                                                     
export FLEEP=`openssl rand -hex 10`
curl -siv -H "Authorization: Token 1-##-##############################" "https://YOURSERVERNAME/REST/2.0/assets?$FLEEP" -X POST --data-binary '
[                                                                               
{ "field": "Name",                                                              
"operator": "LIKE",                                                             
"value": "Test Asset" }                                                              
]'

Give that a shot and see if it is consistent or not.

Thanks for the feedback.

  We are on 4.4.2.  I ran the caching test as suggested.  The

results were the same, the returned “items” were null. I passed
along your suggestion to the admins to look at NginX settings.

  Thanks again for the response.  If we figure it out, I will post

it. The admins stated that there have been other reports similar
to mine in the REST2 bugs and they are going to post a bug report.

Hi Barry,

I was checking the open bugs for RT-Extension-REST2 and it looks like this problem, or a variant of it have been reported:

https://rt.cpan.org/Public/Bug/Display.html?id=127580
https://rt.cpan.org/Public/Bug/Display.html?id=123261

In the first one, issuing a normal asset search made the JSON search work. I tried that and while it did make it work much more reliably it was still failing. Without the regular search, it would fail 19 times out of 20 tries.

Regards,
Ken

When I set the no-cache as a header it seems to perform better as
defined in 127580 below, but it still occasionally fails (4 out of
20 failed).

-H ‘Cache-Control: no-cache’:wq

Interestingly, both of those appear to be using nginx web servers as well. Whereas we’re using Apache/FastCGI which seems to work fine.

Hi,

We are also running 4.4.2 and not 4.4.4. It looks like there were several asset related changes committed after our version.

Regards,
Ken