Packs_per_day query not reporting correct data for the date filter

supritha · July 16, 2021, 4:59am

Hi,

We want to run a query every 15 minutes to check on the recent packs and ensure items were all scanned.
But looking at the response of packs_per_day with date_from and date_to filter, it is returning results 5 hours and 51 minutes ahead.

Below is the query with the date range filter.

query {
    packs_per_day(date_from: "2021-05-26T14:30:03" date_to: "2021-05-26T14:30:04") {
            request_id
            complexity
            data {
            pageInfo {
            hasNextPage
            hasPreviousPage
            startCursor
            endCursor
        }
        edges {
            node {
                    id
                    shipment_id
                    warehouse_id
                    total_items
                    unique_items
                    barcodes_scanned
                    user_first_name
                    user_last_name
                    created_at
                    order {
                        id
                        order_number
                    }
                }
            cursor
            }
        }
    }
}

This query returned result with created_at: “2021-05-26T20:21:03”.

request_id: “60f008f1bba32db49eb08add”

Theresa · July 16, 2021, 6:33pm

Hi,
I just did the same query,

query {
  packs_per_day(
    date_from: "2021-07-16T12:00:03"
    date_to: "2021-07-16T14:00:00"
  ) {
    request_id
    complexity
    data {
      pageInfo {
        hasNextPage
        hasPreviousPage
        startCursor
        endCursor
      }
      edges {
        node {
          id
          shipment_id
          warehouse_id
          total_items
          unique_items
          barcodes_scanned
          user_first_name
          user_last_name
          created_at
          order {
            id
            order_number
          }
        }
        cursor
      }
    }
  }
}

and the results included “order_number”: “002183194” which seems to be spot-on for the results. I am not too sure why May is giving you problems, and it would be very difficult to go back that far. Do you have a recent example of the same issue?

supritha · July 17, 2021, 8:21am

Hi Theresa,

Below is the recent example with request_id,
which is also returning results 5 hours and 51 minutes ahead.

query {
  packs_per_day(
    date_from: "2021-07-16T12:00:00"
    date_to: "2021-07-16T12:01:00"
  ) {
    request_id
    complexity
    data {
      pageInfo {
        hasNextPage
        hasPreviousPage
        startCursor
        endCursor
      }
      edges {
        node {
          id
          shipment_id
          warehouse_id
          total_items
          unique_items
          barcodes_scanned
          user_first_name
          user_last_name
          created_at
          order {
            id
            order_number
          }
        }
        cursor
      }
    }
  }
}

This query returned result with created_at: “2021-07-16T17:51:48”
request_id: “60f28e6e3268dd09e92befb1”

supritha · July 19, 2021, 10:38am

For Packs and Picks per day API:

the inconsistency of user details in the response of Shiphero API, there are some user’s data that will be available in the API response, but the same user information itself is not present on the Shiphero platform screen. The same happens vice versa, user packer logs are not present in API response while it’s available on the screen.

for example,

if you check the logs from API response for April 6th and July 8th: Tekita Williams, this user is not available on the ShipHero screen but API fetched picker logs for him/her.
27-5-2021 12:38 pm CST in screen, Nate Reynolds packer log not available in Shiphero API response.

the above is only what we have caught, but there may exist more such inconsistencies.

Please have a look at it.

Theresa · July 23, 2021, 5:40pm

I will send the 5 hour difference that packs_per_day is returning over to engineering. Thank you for the very direct example!

supritha · July 29, 2021, 1:26pm

Hi Theresa,

Any update on this?

Theresa · July 29, 2021, 5:07pm

It is still in the queue. I will see if I can get it prioritized. Thank you for the heads up!

Theresa · August 3, 2021, 2:15pm

Hi @supritha we are working on getting in, we will keep you up to date as it progresses. Right now, it is still in queue

supritha · August 16, 2021, 10:12am

Hi, @Theresa any update on the above request.

Theresa · August 16, 2021, 4:05pm

Hi @supritha
I just checked and it should have some review in the next few days.

Theresa · September 13, 2021, 2:31pm

This is showing as complete from engineering. @supritha

askthebird · September 14, 2021, 7:28pm

@Theresa
I’m now seeing something similar to the original issue.

If I run @supritha’s original query with dates of 2021-09-14T14:00:00.000Z through 2021-09-14T19:00:00.000Z. I get 13 results, so a little over 400 missing. Our peoples’ reviews & bonuses depend on this API. Those date strings are 8601-compliant.

The request_id for that was 6140f6de17f3bdf17b489512

Theresa · September 14, 2021, 7:39pm

Thank you, I will check this out

supritha · September 17, 2021, 1:57pm

Hi Theresa,

We tried to get the result using the below-mentioned query. But it is returning results 5 hours ahead. It seems like we need to pass CST to get the result in UTC.

Which timezone do we need to pass in the query ( UTC or CST)?

Query:

query {
packs_per_day(date_from: “2021-09-10T13:54:00” date_to: “2021-09-10T13:54:56”) {
request_id
complexity
data {
pageInfo {
hasNextPage
hasPreviousPage
startCursor
endCursor
}
edges {
node {
id
shipment_id
warehouse_id
total_items
unique_items
barcodes_scanned
user_first_name
user_last_name
created_at
order {
id
order_number
}
}
cursor
}
}
}
}

Please find the request-id for that.

        "request_id": "61449b6d5c1f619f9668a89f",

Theresa · September 17, 2021, 9:23pm

Hi @supritha
Thank you for the request-id. I will look into this further

askthebird · September 27, 2021, 2:01pm

Hi Theresa,

We are at 13 days where our warehouse kpi/bonus system has been shut down due to being unable to retrieve accurate results from packs_per_day queries with date filters.

Can you provide any update on this? As it stands now, I don’t even know if this has been triaged. Can you confirm that the returns from this query are indeed unexpected/inaccurate?

Theresa · September 27, 2021, 10:10pm

Hi @askthebird, I just ran the same query on your account and got the first 100. This is the result of request-id 6140f6de17f3bdf17b489512. The only thing that I did differently was to add the dates of the variables instead of variables. Could it be there was some type of error in the variables? This is what I ran.

query {
  packs_per_day(
    date_from: "2021-09-14T14:00:00.000Z"
    date_to: "2021-09-14T19:00:00.000Z"
  ) {
    request_id
    complexity
    data(first: 100) {
      pageInfo {
        hasNextPage
        endCursor
      }
      edges {
        node {
          id
          created_at
          user_id
          user_first_name
          user_last_name
          order_id
          order_number
          barcodes_scanned
          total_items
          unique_items
          order {
            order_date
          }
        }
      }
    }
  }
}

askthebird · September 29, 2021, 7:51pm

Hi @Theresa
That example query you provided does indeed return results for me now. In fact, all of my time-filtered queries seem to return results as expected some hours after the time windows have passed.

If I query more recent data, the results are almost always empty.
Example:

query {
    packs_per_day(date_from: "2021-09-29T18:59:59.999Z", date_to: "2021-09-29T19:30:00.000Z") {
        request_id
        complexity
        data(first:100) {
            pageInfo {
                hasNextPage
                endCursor
            }
            edges {
                node {
                    id
                    created_at
                    user_id
                    user_first_name
                    user_last_name
                    order_id
                    order_number
                    barcodes_scanned
                    total_items
                    unique_items
                    order {
                        order_date
                    }
                }
            }
        }
    }
}

Result:

{
  "data": {
    "packs_per_day": {
      "request_id": "6154c1767a5c91ecc16fb285",
      "complexity": 101,
      "data": {
        "pageInfo": {
          "hasNextPage": false,
          "endCursor": null
        },
        "edges": []
      }
    }
  }
}

That time window is meant to represent fulfillment creations between 13:59:59 and 14:30:00 US Central time. During this time window, a significant amount of bulk & regular shipping was being performed.

If I omit the UTC/zulu specification and convert it to local (Central) time, I get the results I expected. Has something changed with your datetime requirements? This format (JS Date.toISOString) had previously been in use for many months without issue.

Theresa · September 29, 2021, 9:13pm

Thank you for the details. There may very well be something that needs attention or has been changed. I have a few posts where the time is sometimes returning unexpected results.

askthebird · September 30, 2021, 2:59pm

I am going to switch to using account-local time for now. I’d prefer being able to specify TZ since that eliminates ambiguity on both ends.

In this case, requests that differ only in the presentation of TZ should return identical results.

Topic		Replies	Views
Picks_per_day query not reporting correct data when using "date_from" - off by 60-80 seconds GraphQL API	10	709	May 12, 2022
Timezone Issue with Picks/Packs Per Day Date Filters GraphQL API	2	96	January 10, 2024
Picks and Packs Question GraphQL API	9	229	April 3, 2023
Date_from filter with timestamps? GraphQL API	2	799	October 1, 2019
ISODateTime instead of Date in packs_per_day query Feedback	3	566	March 16, 2021

Packs_per_day query not reporting correct data for the date filter

Related Topics