Add /indigo:debug-sqllogger skill + command#30
Conversation
Walks through debugging which Indigo devices are causing the generic "SQL Logger Error: One or more failures updating device history" spam. Promotes the two swallowed logger.debug(..., exc_info=True) calls to error-level via a [DEBUG-PATCH]-tagged edit, extracts the failing device_history_<id> + exception, resolves the device via MCP, and asks the user which of three fixes to apply (exclude device / exclude states / drop + rebuild table). Reverts every patch on the way out; grep-verifies cleanup. Interactive only. One device per pass. SQL DROP is hardcoded to the specific device ID extracted during the run — never parameterised. Bumps plugin version 1.7.0 → 1.8.0 (minor: new user-visible feature). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 52 minutes and 7 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR updates the plugin version from 1.7.0 to 1.8.0 in the manifest files and introduces comprehensive documentation for a new SQL Logger debugging workflow, including both a command specification and a detailed skill guide for diagnosing and resolving device history errors. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Five fixes from code-reviewer + direct source verification against
the installed SQL Logger plugin on jarvis:
1. Correct the create-path patch example — line 476 in the real
SQL Logger source does NOT carry exc_info=True (only line 529
does). Skill now shows both before/after snippets accurately and
tells agents to add exc_info=True when promoting, otherwise the
traceback never lands in the log and the patch is useless.
2. Fix the update-path example message text to match reality
("with device changes" not "for device {dev.id}"). Edit-tool
matching would have failed cold otherwise.
3. Inline the mount-prefix probe (same loop used in
update-plugins/references/install-workflow.md § "Deploy path
portability") so a cold agent doesn't have to go hunting, and
add an explicit canonical reference for the full pattern.
4. Promote the "revert on any abort" rule to a Safety Rule and wire
it into Phase 4's "none" branch. Previously nothing prevented a
mid-flow interrupt from leaving [DEBUG-PATCH] logger.error calls
in plugin.py spamming the event log every 60s.
5. Clarify Phase 7's "re-run from Phase 2" — Phase 6 has already
reverted the patch, so the "next device" case needs a full
Phase 2 → 7 re-patch cycle, not just re-reading the log.
Also: defence-in-depth on the Option (c) DROP statement — assert
<id> matches ^[0-9]+$ before embedding in SQL. Indigo device IDs
are always ints, but a Phase 3 extraction bug could theoretically
produce something else; cheap to guard.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 participant
Summary
New
/indigo:debug-sqlloggercommand that walks through identifying which Indigo device is causing the repeating generic "SQL Logger Error: One or more failures updating device history" message, then applies one of three user-chosen fixes and reverts all temporary patches.SQL Logger swallows per-device exceptions behind
self.logger.debug(..., exc_info=True). WithsqlDebugLoggingdisabled (the default), the event log only shows a generic spam line every ~60s with no device ID and no traceback. This skill codifies the workflow I used by hand:logger.debugcall sites (_update_device_history,_create_table_for_dev) tologger.errorvia a[DEBUG-PATCH]-taggedEditindigoplugin.sql-logger/plugin.log, extract the failingdevice_history_<id>+ exception classmcp__indigo__get_device_by_id, cross-reference the state list for overflow candidates (INT4 cumulative counters are the usual cause —NumericRangeError, PG code22003)sharedProps["sqlLoggerIgnoreStates"] = "*", via Indigo UI)DROP TABLE IF EXISTS device_history_<id>instartup(), reverted immediately after the rebuild confirmation line appears)[DEBUG-PATCH]edit,grepto confirm zero hits remain, restart, watch event log to verify the error stopsSafety
[DEBUG-PATCH]; revert is grep-verifiedDROPstring hardcodes the specific<id>extracted in Phase 3 — never parameterised from elsewheremcp__indigo__list_pluginswith workspace mount-prefix handling (same pattern/indigo:update-pluginsuses) — nothing hardcodedVersion
plugin.json+marketplace.json: 1.7.0 → 1.8.0 (minor: new user-visible feature)Test plan
/indigo:debug-sqlloggerloads on a session with no active SQL Logger errors and exits cleanly at Phase 1 (nothing to debug)SQL Loggerplugin and its log path, promotes bothlogger.debugcalls with[DEBUG-PATCH]tags, restart + log extraction surface the real exception +device_history_<id>get_device_by_idresolves the device and the report names itgrep [DEBUG-PATCH]returns zero, event log silence verified🤖 Generated with Claude Code
Summary by CodeRabbit
Chores
Documentation