Skip to content

fix(tui): calendar segment reads producer event 'name' not 'title'#156

Merged
vishnujayvel merged 1 commit into
mainfrom
fix/calendar-segment-event-name
Jun 17, 2026
Merged

fix(tui): calendar segment reads producer event 'name' not 'title'#156
vishnujayvel merged 1 commit into
mainfrom
fix/calendar-segment-event-name

Conversation

@vishnujayvel

@vishnujayvel vishnujayvel commented Jun 17, 2026

Copy link
Copy Markdown
Owner

Part of #155 (calendar half). Canonical side per maintainer decision: Python adapts to the Go producer.

Bug

The calendar status-line renderer reads event title, but the Go calendar producer + CalendarTestFixture emit event name. FlattenForTUI spreads producer fields verbatim (no rename layer in data.py), so in production:

  • a current event rendered 📅 ?
  • an upcoming event fell through to 📅 Free (the next_event.get("title") guard was always falsy)

This is the Go→JSON→Python field-drift class (cf. weather bug #29).

Fix

  • tui/hookwise_tui/tabs/status.py: the calendar block's four current/next_event title reads → name. The news segment's story["title"] is a distinct, correct field and is untouched.
  • tui/tests/test_status_segments.py (new): feeds a producer-shaped calendar fixture into _render_segment and asserts the event name renders — red before, green after.

Verification

  • New tests fail on main (📅 Free / ?), pass after the fix.
  • Full TUI suite: 56 pass + 2 new pass; the 2 snapshot failures (analytics, feeds) are pre-existing on clean main (verified by stash) and unrelated.

Project half of #155 (renderer reponame, detacheddirty, producer adds last_commit_ts) follows in a separate PR.

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Bug Fixes

    • Fixed calendar event display to correctly show event names in the status line, preventing fallback text from appearing when event data is available.
  • Tests

    • Added test coverage to verify calendar events render with proper names and prevent regressions in event display.

The calendar status-line renderer read event 'title', but the Go calendar
producer (and CalendarTestFixture) emit event 'name'. FlattenForTUI spreads
producer fields verbatim with no rename layer, so in production the current
event rendered '?' and an upcoming event fell through to "📅 Free" -- the
Go->JSON->Python field-drift class (cf. weather bug #29). Part of issue #155;
canonical side is the Go producer (consistent + fixtured + tested), matching
how the weather/insights segments already work.

Switch the renderer's four next_event/current title reads to name. Add
tests/test_status_segments.py asserting a producer-shaped calendar fixture
renders the event name (red before, green after). News-segment story 'title'
is a distinct, correct field and is untouched.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jun 17, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: d67df203-220e-4215-be0d-164f7665b02a

📥 Commits

Reviewing files that changed from the base of the PR and between e0d7729 and e21f208.

📒 Files selected for processing (2)
  • tui/hookwise_tui/tabs/status.py
  • tui/tests/test_status_segments.py

📝 Walkthrough

Walkthrough

In StatusTab._render_segment, all calendar segment event display reads are changed from "title" to "name" on both current and next_event objects across every rendering path. A new test module adds two cross-boundary tests that build cache fixtures with the name field and assert correct rendered output.

Changes

Calendar segment field-name fix and regression tests

Layer / File(s) Summary
Calendar segment renderer: titlename
tui/hookwise_tui/tabs/status.py
All event display text in the calendar segment renderer is switched from current["title"]/next_event["title"] to current["name"]/next_event["name"] across all rendering paths (current event, free/fallback, ISO parse failure, and countdown).
Cross-boundary regression tests
tui/tests/test_status_segments.py
New test module with a TestCalendarSegment class containing two methods: one verifies a current event renders the producer name without degraded output, and one verifies the next-event path renders name rather than "Free".

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related issues

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: updating the calendar segment to read the 'name' field from producer events instead of 'title'.
Description check ✅ Passed The description is comprehensive and well-structured, covering the bug, fix, verification, and motivation. It includes the issue reference (#155) and test coverage details.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/calendar-segment-event-name

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@vishnujayvel vishnujayvel merged commit b9080f7 into main Jun 17, 2026
6 checks passed
@vishnujayvel vishnujayvel deleted the fix/calendar-segment-event-name branch June 17, 2026 04:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant