Side tab runs sorting

[Demonstrandum]

Motivation for features / changes

Previously, runs in the side tab were sorted alphabetically by run name. The backend already had start_time data but only returned run names as strings, which the frontend then re-sorted. This change addresses the user request to order runs by the time they were added, providing a more intuitive default sort order and the ability to sort by start time.

Technical description of changes

This is a full-stack change across 12 files:

1. Backend (core_plugin.py): The /data/runs endpoint now returns a list of objects [{"name": "run1", "startTime": 1234.0}, ...] instead of plain strings ["run1", ...]. startTime is null if no events have been recorded.
2. Angular Frontend (runs_data_source.ts): Updated to parse the new object format and use actual startTime values.
3. Legacy Polymer (runsStore.ts): Modified extractRunNames() to handle both the new object format and the old string format for backward compatibility.
4. Runs Table UI (runs_reducers.ts, runs_table_container.ts, runs_data_table.*):
   • A new "Started" column has been added to the runs table, which is sortable.
   • The default sort order for runs is now startTime ascending (oldest first), matching the "order added" request.
   • startTime is included in the TableData for sorting.
   • The "Started" column displays human-readable timestamps: time-only for today's runs (e.g., "10:30 AM"), month and day for older runs (e.g., "Jan 15"). A full timestamp is shown on hover via a tooltip.
5. Tests: Backend tests (core_plugin_test.py) verify the new object format and timestamp values. Frontend data source tests (runs_data_source_test.ts) verify parsing. Runs table tests (runs_table_test.ts) were updated to expect the new startTime field in TableData.
6. Documentation (AGENTS_DEV.md): Updated to reflect the new sorting behavior and "Started" column.

Users can still click any column header (Run, Experiment, Hparams, etc.) to change the sort order.

Screenshots of UI changes (or N/A)

N/A

Detailed steps to verify changes work correctly (as executed by you)

1. Start the TensorBoard application.
2. Navigate to the runs side tab (usually on the left).
3. Observe the runs list:
   • Verify a new column labeled "Started" is present, typically next to the "Run" column.
   • Confirm that runs are sorted by the "Started" time in ascending order (oldest first) by default.
4. Click on the "Started" column header to reverse the sort order (newest first).
5. Click on other column headers (e.g., "Run") to ensure that sorting by other criteria still functions correctly.
6. Check the formatting of the "Started" column:
   • For runs started today, verify only the time is displayed (e.g., "10:30 AM").
   • For runs started on previous days, verify the month and day are displayed (e.g., "Jan 15").
   • Hover over a "Started" time to confirm a tooltip appears showing the full timestamp.
7. (Optional, for developers) Inspect the network request to /data/runs to confirm the backend returns objects with name and startTime fields.

Alternate designs / implementations considered (or N/A)

N/A

  

[cursor]

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
_{Learn more about Cursor Agents}

[github-actions]

Preview Deployment

Status	✅ Running
Live Preview	https://Demonstrandum-tensorbored-pr-69.hf.space
Space	https://huggingface.co/spaces/Demonstrandum/tensorbored-pr-69

Details

• Wheel: tensorbored_nightly-2.21.0a20260313-py3-none-any.whl
• Commit: 06d0b36
• Build status: success

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Null startTime mapped to 0 inverts sort order
  • Changed the null startTime fallback from 0 to Infinity in runs_data_source.ts to match the backend's float('inf') sort semantics, ensuring eventless runs sort last in ascending order.

Or push these changes by commenting:

@cursor push 4c7bc6c61b

Preview (4c7bc6c61b)

diff --git a/tensorbored/webapp/runs/data_source/runs_data_source.ts b/tensorbored/webapp/runs/data_source/runs_data_source.ts
--- a/tensorbored/webapp/runs/data_source/runs_data_source.ts
+++ b/tensorbored/webapp/runs/data_source/runs_data_source.ts
@@ -42,7 +42,7 @@
             return {
               id: runToRunId(entry.name, experimentId),
               name: entry.name,
-              startTime: entry.startTime ?? 0,
+              startTime: entry.startTime ?? Infinity,
             };
           });
         })

diff --git a/tensorbored/webapp/runs/data_source/runs_data_source_test.ts b/tensorbored/webapp/runs/data_source/runs_data_source_test.ts
--- a/tensorbored/webapp/runs/data_source/runs_data_source_test.ts
+++ b/tensorbored/webapp/runs/data_source/runs_data_source_test.ts
@@ -51,7 +51,7 @@
       ]);
     }));
 
-    it('treats null startTime as 0', fakeAsync(() => {
+    it('treats null startTime as Infinity', fakeAsync(() => {
       const results = jasmine.createSpy();
       dataSource.fetchRuns('exp1').subscribe(results);
 
@@ -61,7 +61,7 @@
       flush();
 
       expect(results).toHaveBeenCalledWith([
-        {id: 'exp1/baz', name: 'baz', startTime: 0},
+        {id: 'exp1/baz', name: 'baz', startTime: Infinity},
       ]);
     }));
   });

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

[cursor]

Null startTime mapped to 0 inverts sort order

High Severity

When the backend returns startTime: null (no events recorded), entry.startTime ?? 0 converts it to 0. Since the default sort is startTime ascending, runs with no events get startTime: 0, which sorts before all real epoch timestamps — placing them at the top. The backend explicitly sorts these runs last using float("inf"). This directly inverts the intended ordering for eventless runs. The fallback value needs to be large (e.g., Infinity) rather than 0 to match the backend's "empty times sorted last" semantics.

Additional Locations (1)

• tensorbored/webapp/runs/store/runs_reducers.ts#L548-L551