Of course, once I cleared the cache, dropped the archives, and truncated the log_ tables, I can't reproduce the above...

For future reference:

GET /index.php?filter_offset=0&module=Actions&action=getPageUrlsSubDataTable&idSite=1&period=day&date=2009-10-29&enable_sort=false&filter_sort_column=nb_visits&filter_sort_order=desc&filter_limit=100&search_recursive=1&viewDataTable=table&controllerActionCalledWhenRequestSubTable=getPageUrlsSubDataTable&totalRows=1&enable_filter_excludelowpop=0&idSubtable=1

This was probably caused in the following case

• default Piwik: real time process every 10 seconds
• Look at reports, they are processed.
• more than 10 seconds later, you click on the row with a given ID
• Piwik re-processes stats for today. The ID you clicked earlier now matches to something different (loads a subtable that doesn't match), or will not load anything.

I don't think any trivial fix for this one.
A solution could be to have a click pass the label of the row, and then use the label to search for the matching parent row, to fetch the subtable. This is not trivial and could lead to some issues.

Could we we pass the label of the row, and if it doesn't match on the server side, we refresh the whole table and expand that row?

This happens to me all the time with Piwik 1.0 and is a major annoyance. I use piwik with "today" as the default displayed day and track referrers in real time, but expanding any row fails to give the proper result once every other try or so.

A solution for this, as vipsoft suggested, would be to add more sanity checks whenever expanding a row. Matching on label as well as id would be a good start. One could even imagine searching for the proper id if the labels don't match, instead of relying on the id itself.

Maybe a solution would be to not trigger a re-archiving when requesting a sub-table, and use the existing pre-processed archive if found? This would be an elegant fix it seems.