Critical Bug Report: Timeline Component Not Displaying All Rows Unless Query is Filtered

What I’m experiencing

When I run the following query:

  SELECT * 
  FROM dummy_machine_schedule s 
   INNER JOIN dummy_machine m ON s.machine_id = m.id;

All expected records are correctly retrieved (confirmed in the table output view), but only a subset of those records is displayed in the Timeline component.

Workaround / Observation

If I add an artificial filter on scheduled_start_date to limit the number of rows:

  SELECT * 
  FROM dummy_machine_schedule s 
  INNER JOIN dummy_machine m ON s.machine_id = m.id 
  WHERE scheduled_start_date < '2025-07-31';

The Timeline then shows the correct records (including, for instance, Project 13, which was missing before).

Screenshots


Timeline missing some items (e.g., Project 13) even though the query returns them


Timeline shows all expected items when the dataset is reduced by a WHERE clause

Additional Notes

This does not appear to be a query issue—the data is present in the response.

It seems the Timeline component fails to render all items when too many rows are passed (even though I'm only retrieving about 30 rows), even if they’re structurally valid.

Expected Behavior

The Timeline component should reliably render all rows returned by the query, not just a subset. If there are rendering or performance limits, the component should at least provide a clear warning or error. As it stands, there's no feedback when data is silently dropped, which makes it impossible to trust that the Timeline reflects the full dataset.

Json extract of my app and csv files with dummy data
boring.json (52.9 KB)
dummy_machine_schedule.csv (3.8 KB)
dummy_machine.csv (440 Bytes)

Thanks for reaching out, @Jinfra!

After taking a look, I'm pretty confident that the behavior you're seeing actually is being caused by the query and not the timeline component. It's a subtle issue - and one that we could absolutely do a better job of surfacing - but the fact that both of the tables you're joining have an id column is causing a conflict when you use SELECT * in your query.

The solution is to specifically enumerate the columns that you want and to alias any that have conflicting names. I've demonstrated this by making a tweak to the app JSON (53.0 KB) that you shared above.

I hope that helps! Let me know if you have any additional questions.

Darren, you are an absolute lifesaver! This is part of an incredibly important project for me. Thank you for being a counterbalance to my stupidity. Please pour yourself a big glass of beer tonight to celebrate your awesomeness.

1 Like