Repository navigation
fix(pending-questions): honor the # Resolved divider in active-question parsers - #1402
Conversation
get_waiting_questions() splits on every `## ` heading across the whole file, so entries kept below the `# Resolved` divider (the audit-trail convention this file has used since mid-May) were miscounted as still pending — the owner got re-notified (macOS + Discord DM + voice) about already-answered questions on every cron fire. Truncate the parsed content at the top-level `# Resolved` divider before splitting. No-op when no such divider exists, so the free-form-delete convention assumed by sonichi#1265 still works unchanged. Verified against the live pending-questions.md: count drops 6 → 3 (the 3 resolved entries are no longer notified). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
get_pending_questions() splits on every `## ` heading across the whole
file, so entries under the `# Resolved` divider were spoken as still
pending in the daily briefing ("6 pending questions" when only 3 are
open). Same divider-blindness as the check-pending-questions fix in
this PR — apply the identical truncation at `^#\s+Resolved\b`.
Verified against the live pending-questions.md: count drops 6 → 3.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
chetanunadkat
changed the title
liususan091219
left a comment
liususan091219
left a comment
There was a problem hiding this comment.
Verdict: LGTM — approve. Correct root-cause fix for the resolved-question miscount, applied symmetrically to both consumers, no-op when the divider is absent. I see this bug live: check-pending-questions.py re-notifies on every cron fire about already-answered items.
Things done right:
-
Root cause is precisely the divider, not the question parser. Both consumers split on
^##file-wide; the audit-trail# Resolvedsection (kept, not deleted) gets swept in. Cuttingcontentat the first# Resolvedbefore the existing##walk is the minimal correct fix — it leaves the proven section-parsing untouched. (src/check-pending-questions.py:87,src/morning-briefing.py:213). -
The regex correctly distinguishes the h1 divider from an h2 question heading.
^#\s+Resolved\brequires whitespace immediately after a single#, so## Resolved follow-up?(a question titled "Resolved…") does NOT match and won't truncate the active region prematurely. That's the subtle case that a naive^# Resolvedor a.find("Resolved")would get wrong — good that this shape avoids it. -
maxsplit=1+[0]is the right idiom: everything before the first divider, and a clean no-op ([whole] → [0]) when there's no# Resolvedat all. Safe on legacy files. -
Symmetric. Both parsers get the identical cut + an explanatory comment, so they can't drift in how they interpret the file.
Non-blocking observations:
- Case/spacing sensitivity: matches
# Resolvedexactly —# resolved,# RESOLVED, or#Resolved(no space) would slip through. Given the convention is fixed (# Resolved), fine as-is;re.IGNORECASEwould be a cheap robustness bump if the divider is ever hand-typed. - DRY: the one-line cut is duplicated across the two files. For a single line that's acceptable, but if a third consumer ever parses this file, a shared
active_region(content)helper (alongside wherever the##walk lives) would keep the divider semantics in one place. - Tests: +11/-0 with no test. The over-count is exactly the regression to guard — a 4-line unit test (
# Resolved-divided fixture → asserts only active sections counted, + a no-divider fixture → unchanged) would lock it cheaply. Not blocking for a fix this small.
Assumes active-above / resolved-below ordering, which matches the file's convention. Clean, scoped, ready to merge.
— Lucy (Mac Studio bot)
liususan091219
left a comment
liususan091219
left a comment
There was a problem hiding this comment.
Verified (triage skill) — bug-fix. The bug: the pending-questions counter swept the whole file, so resolved questions were miscounted as pending and re-notified the owner about already-answered questions. The fix cuts content at the '# Resolved' divider before counting (check-pending-questions.py + morning-briefing.py); no-op when there's no divider. CI green, mergeable, CLA passing. — Lucy (Mac Studio bot)
|
@cla-assistant check |
Problem
Two consumers parse
pending-questions.mdby splitting on every##heading across the whole file, ignoring the top-level# Resolveddivider that answered questions are filed under (an audit-trail convention this file has used since mid-May). So resolved questions are counted as still-open:src/check-pending-questions.py— the cron re-notifies the owner (macOS + Discord DM + voice) about already-answered questions on every fire.src/morning-briefing.py— the daily spoken briefing says "6 pending questions" when only 3 are open, and can read out a resolved item as the "top" question.Observed live: both report 6 when the active section has 3.
Fix
In both parsers, truncate the parsed content at the
# Resolveddivider before splitting:# Resolveddivider, so the free-form / delete-on-resolve convention assumed by fix(check-pending-questions): treat free-form sections as unanswered #1265 keeps working unchanged.Verification
Against the live
pending-questions.md, bothget_waiting_questions()andget_pending_questions()drop 6 → 3 (only genuinely-open entries remain).python3 -m py_compileclean on both files. Single concern (one bug class, identical one-line fix in two parsers).Related (not in this PR)
A separate, opposite bug class exists in
dashboard.py,agent-api.py, andfriction-detector.py: they require**Status:**markers that the current free-form file never has, so they undercount to 0. That's a format-recognition fix (align with #1265's "no status = unanswered"), filed separately to keep this PR single-concern.🤖 Generated with Claude Code