Rally - Lookback API: TotalResultCount value is matching the Start parameter value

Products

• CA Agile Central SaaS (Rally)

Issue/Introduction

In some situations, the TotalResultCount returned in the response of a Lookback API (LBAPI) query will not reflect the actual total of the results that would be returned, but instead shows the value specified for the "start" parameter in the payload.

For example, the following query returns 626 records in our test environment with a start value of 0:

{
 "find": 
 {
  "_TypeHierarchy": "HierarchicalRequirement",
  "Children": null,
  "ScheduleState": {
   "$lt": "Accepted"
     },
     "__At": "2019-07-23T00:00-05:00"
    },
 "fields":["Owner","ObjectID", "_ValidFrom", "_ValidTo", "Iteration", "FormattedID", 
              "ScheduleState","Feature","Name","PortfolioItem","Project","PlanEstimate",
              "Blocked"],
 "hydrate":["Project", "Iteration", "ScheduleState"],
  "compress": true,
  "start": 0
}

Response:

{"_rallyAPIMajor":"2","_rallyAPIMinor":"0","Errors":[],"Warnings":[],"GeneratedQuery":{"find":
{"_TypeHierarchy":{"$in":[-51038,10487547445,198278167240]},"Children":null,"ScheduleState":
{"$in":[null,198278166516,198278166532,198278166508,198278166524]},
"$and":[{"_ValidFrom":{"$lte":"2019-07-23T05:00:00.000Z"},"_ValidTo":{"$gt":"2019-07-23T05:00:00.000Z"}}],
"_ValidFrom":{"$lte":"2020-05-06T21:35:03.321Z"}},"limit":100,"skip":0,
"fields":{"Owner":1,"ObjectID":1,"_ValidFrom":1,"_ValidTo":1,"Iteration":1,"ScheduleState":1,"Feature":1,"Name":1,
"PortfolioItem":1,"Project":1,"PlanEstimate":1,"Blocked":1,"_UnformattedID":1,"_TypeHierarchy":"['$slice': -1]"},
"compress":true},"TotalResultCount":626,"HasMore":true,"StartIndex":0,"PageSize":100,
"ETLDate":"2020-05-06T21:35:03.321Z","CompressedResultCount":100,"Results":[{"_ValidFrom":"2018-09-20T14:13:40.978Z",
"_ValidTo":"2020-02-05T20:30:54.962Z","ObjectID":204107641384,"Project":{"ObjectID":203714268060,"Name":"Project 22"}
...Results truncated...}

However, when the start value is changed to a number larger than the actual TotalResultCount, the TotalResultCount value becomes the same as the number specified in the start value:

{
 "find": 
 {
  "_TypeHierarchy": "HierarchicalRequirement",
  "Children": null,
  "ScheduleState": {
   "$lt": "Accepted"
     },
     "__At": "2019-07-23T00:00-05:00"
    },
 "fields":["Owner","ObjectID", "_ValidFrom", "_ValidTo", "Iteration", "FormattedID", 
              "ScheduleState","Feature","Name","PortfolioItem","Project","PlanEstimate",
              "Blocked"],
 "hydrate":["Project", "Iteration", "ScheduleState"],
  "compress": true,
  "start": 1234
}

Results:

{"_rallyAPIMajor":"2","_rallyAPIMinor":"0","Errors":[],"Warnings":[],"GeneratedQuery":{"find":{"_TypeHierarchy":{
"$in":[-51038,10487547445,198278167240]},"Children":null,"ScheduleState":{"$in":[null,198278166516,198278166532,
198278166508,198278166524]},"$and":[{"_ValidFrom":{"$lte":"2019-07-23T05:00:00.000Z"},"_ValidTo":{
"$gt":"2019-07-23T05:00:00.000Z"}}],"_ValidFrom":{"$lte":"2020-05-06T21:35:03.321Z"}},"limit":100,"skip":1234,
"fields":{"Owner":1,"ObjectID":1,"_ValidFrom":1,"_ValidTo":1,"Iteration":1,"ScheduleState":1,"Feature":1,"Name":1,
"PortfolioItem":1,"Project":1,"PlanEstimate":1,"Blocked":1,"_UnformattedID":1,"_TypeHierarchy":"['$slice': -1]"},
"compress":true},"TotalResultCount":1234,"HasMore":false,"StartIndex":1234,"PageSize":100,
"ETLDate":"2020-05-06T21:35:03.321Z","CompressedResultCount":0,"Results":[],"ThreadStats":{"cpuTime":"35.70207",
"waitTime":"0","waitCount":"0","blockedTime":"0","blockedCount":"0"},"Timings":{"preProcess":0.0,"findEtlDate":178.0,
"allowedValuesDisambiguation":32.0,"mongoQuery":19.0,"authorization":1.0,"formattedId":0.0,
"suppressNonRequested":0.0,"compressSnapshots":0.0,"allowedValuesHydration":0.0,"TOTAL":230.0}}

Cause

This is due to how the underlying database handles record calculation and the fact that the query is attempting to access data beyond the bounds of the actual records that were retrieved.

Resolution

This is not an indication that there are actually 1234 records as shown in the example above, merely that there has been an attempt to access more records than were actually returned by the query.  Reducing the start value to a number that is equal to or below the actual number of records returned by the query will allow the TotalResultCount to represent an accurate count of records that is available to that user for this query.