fix: handle null/undefined token values in ContextCondenseRow to prevent UI crash

[roomote]

Summary

This PR fixes a UI crash that occurs when the ContextCondenseRow component receives null or undefined values for token counts. The error "Cannot read properties of null (reading 'toLocaleString')" was causing the entire UI to crash, as reported in issue #6914.

Problem

The ContextCondenseRow component was attempting to call .toLocaleString() on prevContextTokens and newContextTokens without checking if these values were null or undefined first. This caused a runtime error that crashed the UI.

Solution

• Added null/undefined checks for prevContextTokens, newContextTokens, and cost values
• Default to 0 when any of these values are null or undefined
• The component now handles edge cases gracefully without crashing

Testing

• Added comprehensive test suite for ContextCondenseRow component
• Tests cover:
  • Normal operation with valid data
  • Handling of null values for all numeric props
  • Handling of undefined values for all numeric props
  • Edge cases like negative numbers and very large numbers
• All tests pass successfully

Related Issues

Fixes #6914

Checklist

• Code changes are tested
• Tests are added for the fix
• All tests pass
• Linting passes
• Type checking passes

---

Important

Fixes UI crash in ContextCondenseRow by handling null/undefined token values and adds comprehensive tests for edge cases.

• Behavior:
  • Fixes UI crash in ContextCondenseRow by handling null/undefined prevContextTokens, newContextTokens, and cost.
  • Defaults to 0 for null/undefined values to prevent .toLocaleString() errors.
• Testing:
  • Adds tests in ContextCondenseRow.spec.tsx for null/undefined handling, valid data, and edge cases like negative and large numbers.
  • Tests ensure component renders correctly and handles all edge cases without crashing.

^{This description was created by for 22a873d. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Reviewing my own code is like debugging in a mirror - everything looks backwards but the bugs are still mine.

[roomote]

I notice we're treating these values as optional here, but the Zod schema in packages/types/src/message.ts defines them as required fields. This creates a type safety issue.

Is this intentional? The schema has:

export const contextCondenseSchema = z.object({
  cost: z.number(),
  prevContextTokens: z.number(),
  newContextTokens: z.number(),
  summary: z.string(),
})

If these values can indeed be null/undefined in practice, we should update the schema to use .number().optional() to maintain type consistency across the codebase.

[roomote]

While defaulting to 0 prevents the crash, could this be misleading to users? When data is unavailable, showing "0 tokens" might imply no tokens were used, when actually the data is missing.

Would it be clearer to display "--" or "N/A" when values are null/undefined?

Suggested change

	const displayCost = cost ?? 0
	const prevTokens = prevContextTokens ?? 0
	const newTokens = newContextTokens ?? 0
	const displayCost = cost ?? 0
	const hasValidData = prevContextTokens != null && newContextTokens != null

[roomote]

Great test coverage for null/undefined cases! One edge case to consider: what happens with NaN values? They would also fail with .toLocaleString(). Might be worth adding a test case:

Suggested change

	})
	it("should handle NaN values without crashing", () => {
	const props = {
	cost: NaN,
	prevContextTokens: NaN,
	newContextTokens: NaN,
	summary: "NaN test",
	}
	const { container } = render(<ContextCondenseRow {...props} />)
	expect(container).toBeInTheDocument()
	// Should handle NaN gracefully
	})

[daniel-lxs]

LGTM