Skip to content

feat(daemon): add status subcommand#156

Merged
AnnatarHe merged 1 commit intomainfrom
feat/daemon-status-command
Dec 25, 2025
Merged

feat(daemon): add status subcommand#156
AnnatarHe merged 1 commit intomainfrom
feat/daemon-status-command

Conversation

@AnnatarHe
Copy link
Copy Markdown
Contributor

Summary

  • Add shelltime daemon status command to check daemon health
  • Displays socket file existence and connectivity with latency
  • Shows service manager status (launchctl on macOS)
  • Reports configuration info (socket path, CCOtel, code tracking)

Test plan

  • Run shelltime daemon status when daemon is running
  • Run shelltime daemon status when daemon is stopped
  • Verify output formatting matches existing patterns from doctor command

🤖 Generated with Claude Code

Add `shelltime daemon status` command that displays:
- Socket file existence and connectivity
- Service manager status (launchctl on macOS)
- Configuration info (socket path, CCOtel, code tracking)

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@gemini-code-assist
Copy link
Copy Markdown
Contributor

Summary of Changes

Hello @AnnatarHe, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new status subcommand for the shelltime daemon, providing users with a quick and comprehensive way to assess the daemon's operational health and current configuration. It checks critical components like socket connectivity and service manager status, offering immediate insights into its running state and configured features.

Highlights

  • New status subcommand: A new status subcommand has been added to the shelltime daemon command, allowing users to check the daemon's health and configuration.
  • Daemon Health Checks: The new command performs several health checks, including verifying the existence of the daemon's socket file, checking connectivity to the daemon with latency measurements, and reporting the status from the system's service manager (e.g., launchctl on macOS).
  • Configuration Display: The status command also displays key configuration information such as the daemon's socket path, and the enabled/disabled status of features like CCOtel and Code Tracking.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@codecov
Copy link
Copy Markdown

codecov Bot commented Dec 25, 2025

Codecov Report

❌ Patch coverage is 0% with 55 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
commands/daemon.status.go 0.00% 55 Missing ⚠️
Flag Coverage Δ
unittests 19.28% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
commands/daemon.status.go 0.00% <0.00%> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@AnnatarHe AnnatarHe merged commit 592954d into main Dec 25, 2025
2 of 3 checks passed
@AnnatarHe AnnatarHe deleted the feat/daemon-status-command branch December 25, 2025 07:42
Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a daemon status command, which is a valuable addition for monitoring the daemon's health. The implementation is well-structured, checking for socket existence, connectivity, and displaying configuration details. I've noted a few areas for improvement to enhance correctness and readability. Specifically, there's a potential issue with how the service manager status is checked, an opportunity to simplify some verbose conditional logic, and a minor output formatting inconsistency. My detailed feedback is in the comments below. Overall, this is a solid and useful feature.

Comment thread commands/daemon.status.go
Comment on lines +53 to +60
installer, installerErr := model.NewDaemonInstaller("", "")
if installerErr == nil {
if err := installer.Check(); err == nil {
printSuccess("Service is registered and running")
} else {
printWarning("Service is not running via system service manager")
}
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Calling model.NewDaemonInstaller with empty strings for baseFolder and username will likely cause the service status check to fail, as the installer needs this information to locate service definition files. You should fetch the current user's details to construct the correct paths, similar to how it's handled in the install and uninstall commands. Note that this change requires importing the os/user and path/filepath packages.

Suggested change
installer, installerErr := model.NewDaemonInstaller("", "")
if installerErr == nil {
if err := installer.Check(); err == nil {
printSuccess("Service is registered and running")
} else {
printWarning("Service is not running via system service manager")
}
}
// Check 3: Service manager status
if currentUser, err := user.Current(); err == nil {
baseFolder := filepath.Join(currentUser.HomeDir, ".shelltime")
if installer, err := model.NewDaemonInstaller(baseFolder, currentUser.Username); err == nil {
if err := installer.Check(); err == nil {
printSuccess("Service is registered and running")
} else {
printWarning("Service is not running via system service manager")
}
}
}

Comment thread commands/daemon.status.go
Comment on lines +66 to +76
if cfg.CCOtel != nil && cfg.CCOtel.Enabled != nil && *cfg.CCOtel.Enabled {
fmt.Printf(" CCOtel: enabled (port %d)\n", cfg.CCOtel.GRPCPort)
} else {
fmt.Println(" CCOtel: disabled")
}

if cfg.CodeTracking != nil && cfg.CodeTracking.Enabled != nil && *cfg.CodeTracking.Enabled {
fmt.Println(" Code Tracking: enabled")
} else {
fmt.Println(" Code Tracking: disabled")
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The nested nil checks for cfg.CCOtel.Enabled and cfg.CodeTracking.Enabled are verbose and repetitive. You can improve readability by extracting the boolean conditions into variables.

Suggested change
if cfg.CCOtel != nil && cfg.CCOtel.Enabled != nil && *cfg.CCOtel.Enabled {
fmt.Printf(" CCOtel: enabled (port %d)\n", cfg.CCOtel.GRPCPort)
} else {
fmt.Println(" CCOtel: disabled")
}
if cfg.CodeTracking != nil && cfg.CodeTracking.Enabled != nil && *cfg.CodeTracking.Enabled {
fmt.Println(" Code Tracking: enabled")
} else {
fmt.Println(" Code Tracking: disabled")
}
ccOtelEnabled := cfg.CCOtel != nil && cfg.CCOtel.Enabled != nil && *cfg.CCOtel.Enabled
if ccOtelEnabled {
fmt.Printf(" CCOtel: enabled (port %d)\n", cfg.CCOtel.GRPCPort)
} else {
fmt.Println(" CCOtel: disabled")
}
codeTrackingEnabled := cfg.CodeTracking != nil && cfg.CodeTracking.Enabled != nil && *cfg.CodeTracking.Enabled
if codeTrackingEnabled {
fmt.Println(" Code Tracking: enabled")
} else {
fmt.Println(" Code Tracking: disabled")
}

Comment thread commands/daemon.status.go
color.Green.Println("Status: Running")
} else {
color.Red.Println("Status: Stopped")
fmt.Println()
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

This extra fmt.Println() call will add a second blank line when the daemon is stopped. The pull request description mentions that output formatting should match existing patterns, and this extra line could create an inconsistency. Removing it will make the output cleaner.

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