Skip to content

Conversation

peteski22
Copy link
Contributor

@peteski22 peteski22 commented Oct 15, 2025

Summary

Implements a complete plugin architecture that allows third-party plugins to intercept and process HTTP requests and responses flowing through the mcpd daemon.

Plugin Configuration (internal/config/)

  • Extended PluginConfig with category-based organization (authentication, authorization, rate limiting, validation, content transformation, audit, observability)
  • Added flow configuration to control whether plugins execute on request, response, or both
  • Implemented plugin metadata validation (commit hash verification)

Plugin Runtime (internal/plugin/)

  • Instance: Wraps plugin implementations with metadata, caching plugin capabilities and enforcing configured flow restrictions
  • Pipeline: Orchestrates plugin execution across categories in a defined order, supporting both serial and parallel execution modes with early termination on rejection
  • Manager: Handles full plugin lifecycle (discovery, process spawning, gRPC connection, graceful shutdown)
  • Adapter: gRPC client adapter implementing the Plugin interface with configurable timeouts
  • Middleware: HTTP middleware integration that processes requests through the plugin pipeline before forwarding to upstream servers

Category Properties

  • Each category defines execution mode (serial/parallel), modification permissions, and rejection behavior
  • Observability runs first for request tracing, authentication/authorization run early for security, audit runs last for logging

Flow Filtering

  • Plugins are only invoked for flows they both support (capabilities) and are configured to handle
  • Prevents unnecessary plugin execution and allows fine-grained control over plugin behavior

Address Generation

  • Uses atomic counter for unique plugin socket/port addresses, eliminating race conditions in concurrent plugin startup

Technical Details

  • Plugins run as separate processes communicating via gRPC over Unix sockets (Unix) or TCP (Windows)
  • Plugin validation checks commit hash matches configuration to ensure correct versions are running
  • Required vs optional plugins: required plugin failures stop the pipeline, optional plugin failures are logged and skipped
  • Pipeline supports request modification by content transformation plugins

Integration

  • Daemon accepts --plugin-dir flag to specify plugin binary directory
  • Plugins are discovered, validated, and started during daemon initialization
  • HTTP middleware wraps the existing API server to intercept all requests

Next steps

  • Follow up PR to support scheduled health checks on running plugins
  • Follow up PRs to support CLI integration for configuration of plugins
  • Follow up PRs for documentation on creating plugins (in addition to existing plugin config)

@peteski22 peteski22 force-pushed the peteski22/plugins-implementation branch from 8c3e492 to 608ff78 Compare October 16, 2025 07:27
@peteski22 peteski22 force-pushed the peteski22/plugins-implementation branch from abeffb9 to f06c04c Compare October 16, 2025 08:22
@agpituk agpituk self-requested a review October 17, 2025 10:14
@peteski22 peteski22 merged commit aeb2d67 into main Oct 21, 2025
3 checks passed
@peteski22 peteski22 deleted the peteski22/plugins-implementation branch October 21, 2025 13:55
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.

2 participants