Describe the bug
The workbench crashed once with At least one object must implement IComparable. and exited to the shell. It has not reproduced since, so this is filed to keep it from being lost rather than as a confirmed repro.
Steps to reproduce
Not reliably reproducible. Observed once under these conditions:
cratis chronicle workbench against a store where a client was actively appending events.- The workbench was launched with a restored
LastNavIndex pointing at a table view (Failures).
- Data changed underneath the view while it was sorted.
Roughly a dozen subsequent launches under similar conditions did not reproduce it.
Expected behavior
A refresh that arrives while a table is sorted re-sorts the rows.
Actual behavior
The workbench terminated and printed:
╭─Error────────────────────────────────────────╮
│ At least one object must implement IComparable. │
╰──────────────────────────────────────────────╯
Environment
- OS: macOS 15 (arm64)
- .NET version: 10.0.x
- Chronicle version: server 16.7.0, CLI built from
main
Additional context
The message is what Comparer<object>.Default throws when asked to order a type that does not implement IComparable — so the likely path is a column comparer falling back to the default comparer on a value it cannot order.
Worth looking at:
FilterableTableView.GetColumnComparer — the base implementation stringifies through BuildRow and is safe, but a view overriding it could return values that are not comparable.- The
col.CustomRowComparer wiring around FilterableTableView.BuildContent, and TableControl.SortByColumn's own fallback when no custom comparer is set.
RebuildRows(), which clears and re-adds rows and then re-applies the sort — the most likely place for a refresh to race a sort.
The relevant history is in project_workbench_pitfalls.md item 3, which records that SortByColumn previously re-sorted with an OrdinalIgnoreCase fallback and was fixed by wiring typed comparers for every column. A null or non-comparable cell reaching that path would produce exactly this exception.
Describe the bug
The workbench crashed once with
At least one object must implement IComparable.and exited to the shell. It has not reproduced since, so this is filed to keep it from being lost rather than as a confirmed repro.Steps to reproduce
Not reliably reproducible. Observed once under these conditions:
cratis chronicle workbenchagainst a store where a client was actively appending events.LastNavIndexpointing at a table view (Failures).Roughly a dozen subsequent launches under similar conditions did not reproduce it.
Expected behavior
A refresh that arrives while a table is sorted re-sorts the rows.
Actual behavior
The workbench terminated and printed:
Environment
mainAdditional context
The message is what
Comparer<object>.Defaultthrows when asked to order a type that does not implementIComparable— so the likely path is a column comparer falling back to the default comparer on a value it cannot order.Worth looking at:
FilterableTableView.GetColumnComparer— the base implementation stringifies throughBuildRowand is safe, but a view overriding it could return values that are not comparable.col.CustomRowComparerwiring aroundFilterableTableView.BuildContent, andTableControl.SortByColumn's own fallback when no custom comparer is set.RebuildRows(), which clears and re-adds rows and then re-applies the sort — the most likely place for a refresh to race a sort.The relevant history is in
project_workbench_pitfalls.mditem 3, which records thatSortByColumnpreviously re-sorted with anOrdinalIgnoreCasefallback and was fixed by wiring typed comparers for every column. A null or non-comparable cell reaching that path would produce exactly this exception.