Dojo gridx occasionally displaying rows in the wrong order

I'm using the Dojo and dojo/gridx that ship with IBM Content Navigator 2.0.3.

The grid data comes from my own global array, which I'm using for other things.

MOST of the time, everything works great. But SOMETIMES the rows get displayed out of order. For example, instead of the expected order {0, 1, 2, 3, 4, 5, 6...} it will display rows {5, 0, 2, 3, 4, 1, 6, ...}. It's like rows are somehow getting "swapped".

I have no idea what could be causing this behavior.

When I look at the gridx store in Chrome Developer tools, the order is OK:

  - this.grid.store:
  add:ƒ ()
  data:Array(11)
    0:{mappedName: "FNOL Email.html", claimNumber: "K00000133690", description: "FNOL", documentType: "", contentRcvDate: "06/11/2018", …, "A1001001A18F11B80705D00000"}
    1:{mappedName: "FNOLAck.msg", claimNumber: "K00000133690", description: "FNOL Acknowledge", documentType: "", contentRcvDate: "06/11/2018", …, "A1001001A18F11B80802G00002"}
    2:{mappedName: "imagefile.gif", claimNumber: "K00000133690", description: "Claim FNOL for Smithers", documentType: "", contentRcvDate: "06/11/2018", …, "A1001001A18F11B80903A00004"}
    3:{mappedName: "2-imagefile.gif", claimNumber: "K00000133690", description: "COR INS16", documentType: "", contentRcvDate: "06/11/2018", …, "A1001001A18F11B81002A00006"}
    4:{mappedName: "MSOutlookMessage.msg", claimNumber: "K00000133690", description: "MSOutlookMessage", documentType: "", contentRcvDate: "06/11/2018", …, "A1001001A18F11B81056G00008"}
    5:{mappedName: "MSWord.doc", claimNumber: "K00000133690", description: "signed medical authorization", documentType: "", contentRcvDate: "06/11/2018", …, "A1001001A18F11B81148F00010"}
    6:{mappedName: "PDF Document.pdf", claimNumber: "K00000133690", description: "Incident Report", documentType: "", contentRcvDate: "06/11/2018", …, "A1001001A18F11B81228B00012"}
   ...

The store's indexes are in the correct order, too:

  idProperty:"cm8DocId"
  index:
    A1001001A18F11B80705D00000:0
    A1001001A18F11B80802G00002:1
    A1001001A18F11B80903A00004:2
    A1001001A18F11B81002A00006:3
    A1001001A18F11B81056G00008:4
    A1001001A18F11B81148F00010:5
    A1001001A18F11B81228B00012:6
    ...

But the rows are displayed out of order on the grid.

When I look at the HTML elements in Chrome developer tools (EXAMPLE: <div class="gridxRow" role="row" rowid="A1001001A18F11B81148F00010" rowindex="0"...>), index 5 is displayed as the top row, rowindex 0. And so forth.

Any ideas why this could possibly be happening?

Any suggestions for troubleshooting?

Solution

I cleaned up some extraneous "imports" from the Dojo widget that contained my grid ... and the problem "disappeared":

define([
 "dojo/_base/declare",
 "dojo/_base/lang",
 "dojo/_base/connect",
 "dojo/dom-style",
 "dijit/_WidgetBase",
 "dijit/_TemplatedMixin",
 "dijit/_Contained",
 "dijit/_WidgetsInTemplateMixin",
 "ecm/model/Request",
 "dijit/layout/ContentPane",
 "gridx/Grid",
 //"gridx/core/model/cache/Sync",
 "dojo/store/Observable",
 "dojo/store/Memory",
 "gridx/modules/select/Row",
 "gridx/modules/extendedSelect/Row",
 "gridx/modules/IndirectSelect",
 "gridx/modules/RowHeader",
 //"gridx/modules/ColumnResizer",
 //"gridx/modules/SingleSort",
 //"gridx/modules/move/Row",
 "gridx/modules/VirtualVScroller",
 "ecm/widget/dialog/BaseDialog",
 //"ecm/widget/_MoveUpDownGridxMixin", 
 "ecm/widget/Button",
 "ecm/widget/CheckBox",
 "myPluginDojo/CustomDownloadDef",  
 "myPluginDojo/CustomPrintCCD",  
 "myPluginDojo/ManifestDef",
 "dojo/text!./templates/ManifestGridWidget.html"

 ],
 function (declare, lang, connect,domStyle, _WidgetBase, _TemplatedMixin, _Contained, _WidgetsInTemplateMixin, 
     Request, ContentPane, Grid, Observable, Memory, SelectRow, ExtendedSelectRow, IndirectSelect, 
     RowHeader,  VirtualVScroller, BaseDialog, Button, CheckBox, 
     CustomDownloadDef, CustomPrintCCD, ManifestDef, template) {    
 return declare("myPluginDojo.ManifestGridWidget", [BaseDialog, _WidgetBase, _TemplatedMixin, _Contained, _WidgetsInTemplateMixin], {
     ...

<= Note the commented out entries.

Even though my code wasn't explicitly USING any of these ... removing the unneeded "imports" from the widget definition (and, presumably, from the runtime environment) seemed to fix the problem (?)