Skip to content

Conversation

@Rekseto
Copy link
Contributor

@Rekseto Rekseto commented Jan 2, 2026

No description provided.

@Rekseto Rekseto self-assigned this Jan 2, 2026
@Rekseto Rekseto linked an issue Jan 2, 2026 that may be closed by this pull request
3 tasks
@Rekseto Rekseto changed the title [WIP] Feature/service discovery Feature/service discovery Jan 6, 2026
@Rekseto Rekseto requested a review from Copilot January 6, 2026 18:06
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR introduces a service discovery system that enables nodes to advertise and discover services from other nodes in the network. The implementation includes a database-backed service registry, a pub/sub mechanism for broadcasting service changes, and shell operations for querying and synchronizing service information.

  • Adds a new services module with discovery, persistence, and synchronization capabilities
  • Implements a ServiceChangeFeed pub/sub mechanism for broadcasting service state changes
  • Integrates the NAT module as an example service discoverer

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 4 comments.

Show a summary per file
File Description
mod/services/module.go Core interface defining the services module API and discovery options
mod/services/service.go Service data structure representing a discoverable service
mod/services/service_change.go Event type for service state changes (enabled/disabled)
mod/services/service_change_feed.go Pub/sub broadcast primitive for service change events
mod/services/src/module.go Main module implementation with remote service discovery logic
mod/services/src/op_discovery.go Shell operation handler for discovering local services with snapshot and follow modes
mod/services/src/op_sync.go Shell operation handler for synchronizing services from a remote identity
mod/services/src/loader.go Module loader with database migration and dependency injection
mod/services/src/deps.go Dependency injection setup that discovers ServiceDiscoverer implementations
mod/services/src/db.go Database operations layer with transaction support
mod/services/src/db_service.go Database model for cached service records
mod/nat/src/service_discoverer.go NAT module's implementation of ServiceDiscoverer interface
mod/nat/src/module.go Added service discovery fields to NAT module
mod/nat/src/loader.go Initialize ServiceChangeFeed in NAT module loader
mod/all/mods.go Register the new services module
Comments suppressed due to low confidence (1)

mod/nat/src/module.go:45

  • The serviceChangeFeed is created in the loader but is never closed when the module shuts down. The Run method (line 41-45) doesn't call Close on the feed before returning. This could lead to resource leaks, particularly goroutines from Subscribe calls that may not properly clean up. Consider adding a defer statement to close the feed when the context is done.
func (mod *Module) Run(ctx *astral.Context) error {
	mod.ctx = ctx.IncludeZone(astral.ZoneNetwork)
	<-ctx.Done()

	return nil

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@Rekseto Rekseto requested a review from cryptoarashi January 8, 2026 11:10
@Rekseto Rekseto force-pushed the feature/service-discovery branch from 81486d5 to 9d7fb5c Compare January 8, 2026 11:21
@Rekseto
Copy link
Contributor Author

Rekseto commented Jan 8, 2026

@cryptoarashi rebased on master to use new channel implementation

Copy link
Contributor

@cryptoarashi cryptoarashi left a comment

Choose a reason for hiding this comment

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

  1. Ops should not contain heavy logic.

Move heavy logic to a module function DiscoverServices(...) (<-chan, error) and
use it in an op. See mod/objects the scope of OpSearch() vs Search(),
OpDescribe() vs Describe().

  1. A single module should be able to expose more than one service. This implementation assumes all services will only post a single service in its snapshot collecting phase.

  2. Object files are missing the init function adding them to the default blueprints.

@Rekseto
Copy link
Contributor Author

Rekseto commented Jan 9, 2026

  1. Ops should not contain heavy logic.

Move heavy logic to a module function DiscoverServices(...) (<-chan, error) and use it in an op. See mod/objects the scope of OpSearch() vs Search(), OpDescribe() vs Describe().

  1. A single module should be able to expose more than one service. This implementation assumes all services will only post a single service in its snapshot collecting phase.
  2. Object files are missing the init function adding them to the default blueprints.

Done @cryptoarashi

@Rekseto Rekseto requested a review from cryptoarashi January 9, 2026 10:51
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.

implement service discovery

3 participants