LFX V2 Mailing List Service

April 7, 2026 Β· View on GitHub

The LFX v2 Mailing List Service is a lightweight proxy microservice that delegates all GroupsIO operations to the ITX HTTP API. Built with Go and the Goa framework, it authenticates via Auth0 M2M OAuth2, translates LFX v2 UUIDs to v1 SFIDs via NATS request/reply, and forwards requests to the ITX backend.

πŸš€ Quick Start

For Deployment (Helm)

Both flows below require the Kubernetes secret to be created first. If the lfx namespace doesn't exist yet, create it:

kubectl create namespace lfx

Then create the secret (values are in 1Password β†’ LFX V2 vault β†’ LFX Platform Chart Values Secrets - Local Development):

kubectl create secret generic lfx-v2-mailing-list-service -n lfx \
  --from-literal=ITX_CLIENT_ID="<value-from-1password>" \
  --from-literal=ITX_CLIENT_PRIVATE_KEY="<value-from-1password>" \
  --from-literal=ITX_AUTH0_DOMAIN="<value-from-1password>" \
  --from-literal=ITX_AUDIENCE="<value-from-1password>" \
  --from-literal=ITX_BASE_URL="<value-from-1password>"

Deploy from GHCR (no local code changes)

Pulls the published image from GHCR β€” no local build required:

make helm-install

Deploy a local build (with code changes)

Build the image locally, then install using the local values override (which sets pullPolicy: Never and the local image repository). Copy the example file first β€” values.local.yaml is not tracked by git so it is safe to modify:

cp charts/lfx-v2-mailing-list-service/values.local.example.yaml \
   charts/lfx-v2-mailing-list-service/values.local.yaml

make docker-build
make helm-install-local

For Local Development

  1. Prerequisites

    • Go 1.24+ installed
    • Make installed
    • Docker (optional, for containerized development)
    • NATS server running (required for ID translation)
  2. Clone and Setup

    git clone https://github.com/linuxfoundation/lfx-v2-mailing-list-service.git
    cd lfx-v2-mailing-list-service
    
    # Install dependencies and generate API code
    make deps
    make apigen
    
  3. Configure Environment

    # For local development with mock translator (no NATS required)
    export TRANSLATOR_SOURCE=mock
    export TRANSLATOR_MAPPINGS_FILE=translator_mappings.yaml
    export AUTH_SOURCE=mock
    export JWT_AUTH_DISABLED_MOCK_LOCAL_PRINCIPAL="test-admin"
    export LOG_LEVEL=debug
    
    # ITX proxy credentials (required even locally unless you stub the proxy)
    # Get ITX_CLIENT_ID and ITX_CLIENT_PRIVATE_KEY from 1Password β†’ LFX V2 vault β†’
    # LFX Platform Chart Values Secrets - Local Development
    export ITX_BASE_URL="https://api.dev.itx.linuxfoundation.org"
    export ITX_CLIENT_ID="your-client-id"
    export ITX_CLIENT_PRIVATE_KEY="$(cat tmp/local.private.key)"
    export ITX_AUTH0_DOMAIN="linuxfoundation-dev.auth0.com"
    export ITX_AUDIENCE="https://api.dev.itx.linuxfoundation.org/"
    
  4. Run the Service

    make run
    

πŸ—οΈ Architecture

The service is a thin proxy layer built using clean architecture:

  • API Layer: Goa-generated HTTP handlers and OpenAPI specifications
  • Service Layer: Orchestrators that resolve v2 UUIDs to v1 SFIDs and forward calls to the ITX proxy
  • Domain Layer: Core business models, typed domain errors, and port interfaces
  • Infrastructure Layer: ITX HTTP proxy client (Auth0 M2M), NATS ID translator, and JWT authentication

Key Features

  • ITX Proxy: All GroupsIO operations (services, mailing lists, members) are delegated to the ITX HTTP API
  • Auth0 M2M Authentication: ITX requests authenticated via private-key JWT assertion with token caching via oauth2.ReuseTokenSource
  • ID Translation: Transparent v2 UUID ↔ v1 SFID mapping via NATS request/reply to the v1-sync-helper service
  • GroupsIO Service Management: List, get, create, update, delete, and find-parent operations for GroupsIO services
  • Mailing List Management: Full lifecycle management including list count and member count endpoints
  • Member Management: Add, get, update, delete, invite, and subscriber-check operations
  • JWT Authentication: Secure API access via Heimdall integration
  • Mock Mode: Complete testing capability without real ITX or NATS dependencies
  • OpenAPI Documentation: Auto-generated API specifications
  • Comprehensive Testing: Unit test coverage with mocks
  • Health Checks: Built-in /livez and /readyz endpoints for Kubernetes probes
  • Structured Logging: JSON-formatted logs with contextual information using Go's slog package
  • v1β†’v2 Data Stream: Consumes DynamoDB change events and publishes them to the indexer and FGA-sync services

πŸ“ Project Structure

lfx-v2-mailing-list-service/
β”œβ”€β”€ cmd/                            # Application entry points
β”‚   └── mailing-list-api/           # Main API server
β”‚       β”œβ”€β”€ design/                 # Goa API design files
β”‚       β”‚   β”œβ”€β”€ mailing_list.go     # Service and endpoint definitions
β”‚       β”‚   └── type.go             # Type definitions and data structures
β”‚       β”œβ”€β”€ eventing/               # v1β†’v2 data stream event processing
β”‚       β”‚   β”œβ”€β”€ event_processor.go  # JetStream consumer lifecycle
β”‚       β”‚   └── handler.go          # Key-prefix router (delegates to internal/service)
β”‚       β”œβ”€β”€ service/                # GOA service implementations and providers
β”‚       β”‚   β”œβ”€β”€ mailing_list_api.go # GOA service implementation
β”‚       β”‚   β”œβ”€β”€ providers.go        # Dependency initialization (auth, translator, ITX config)
β”‚       β”‚   └── converters.go       # Domain ↔ GOA type converters
β”‚       β”œβ”€β”€ data_stream.go          # Data stream startup wiring and env config
β”‚       β”œβ”€β”€ main.go                 # Application entry point
β”‚       └── http.go                 # HTTP server setup
β”œβ”€β”€ charts/                         # Helm chart for Kubernetes deployment
β”‚   └── lfx-v2-mailing-list-service/
β”‚       β”œβ”€β”€ templates/              # Kubernetes resource templates
β”‚       β”œβ”€β”€ values.yaml             # Production configuration
β”‚       └── values.local.yaml       # Local development configuration
β”œβ”€β”€ docs/                           # Additional documentation
β”‚   └── event-processing.md         # v1β†’v2 data stream event processing
β”œβ”€β”€ gen/                            # Generated code (DO NOT EDIT)
β”‚   β”œβ”€β”€ http/                       # HTTP transport layer
β”‚   β”‚   β”œβ”€β”€ openapi.yaml            # OpenAPI 2.0 specification
β”‚   β”‚   └── openapi3.yaml           # OpenAPI 3.0 specification
β”‚   └── mailing_list/               # Service interfaces
β”œβ”€β”€ internal/                       # Private application code
β”‚   β”œβ”€β”€ domain/                     # Business domain layer
β”‚   β”‚   β”œβ”€β”€ errors.go               # Typed domain errors (DomainError with constructors)
β”‚   β”‚   β”œβ”€β”€ model/                  # Domain models (GroupsIOService, GroupsIOMailingList, GrpsIOMember)
β”‚   β”‚   └── port/                   # Repository and service interfaces
β”‚   β”‚       β”œβ”€β”€ translator.go       # Translator interface (MapID v2↔v1)
β”‚   β”‚       └── mapping_store.go    # MappingReader / MappingWriter / MappingReaderWriter
β”‚   β”œβ”€β”€ service/                    # Service layer implementation
β”‚   β”‚   β”œβ”€β”€ grpsio_service_reader.go         # Service reader orchestrator
β”‚   β”‚   β”œβ”€β”€ grpsio_service_writer.go         # Service writer orchestrator
β”‚   β”‚   β”œβ”€β”€ grpsio_mailing_list_reader.go    # Mailing list reader orchestrator
β”‚   β”‚   β”œβ”€β”€ grpsio_mailing_list_writer.go    # Mailing list writer orchestrator
β”‚   β”‚   β”œβ”€β”€ grpsio_member_reader.go          # Member reader orchestrator
β”‚   β”‚   β”œβ”€β”€ grpsio_member_writer.go          # Member writer orchestrator
β”‚   β”‚   β”œβ”€β”€ datastream_service_handler.go    # v1-sync service transform + publish
β”‚   β”‚   β”œβ”€β”€ datastream_subgroup_handler.go   # v1-sync mailing list transform + publish
β”‚   β”‚   └── datastream_member_handler.go     # v1-sync member transform + publish
β”‚   β”œβ”€β”€ infrastructure/             # Infrastructure layer
β”‚   β”‚   β”œβ”€β”€ auth/                   # JWT authentication
β”‚   β”‚   β”œβ”€β”€ proxy/                  # ITX HTTP proxy client
β”‚   β”‚   β”‚   β”œβ”€β”€ itx.go              # ITX client (implements all GroupsIO port interfaces)
β”‚   β”‚   β”‚   β”œβ”€β”€ types.go            # Wire types for ITX API requests/responses
β”‚   β”‚   β”‚   └── converters.go       # Domain ↔ wire type converters
β”‚   β”‚   β”œβ”€β”€ nats/                   # NATS messaging and ID translation
β”‚   β”‚   β”‚   β”œβ”€β”€ translator.go       # NATS request/reply ID translator
β”‚   β”‚   β”‚   β”œβ”€β”€ mapping_store.go    # MappingReaderWriter backed by JetStream KV
β”‚   β”‚   β”‚   β”œβ”€β”€ messaging_publish.go # Message publishing
β”‚   β”‚   β”‚   └── client.go           # NATS connection management
β”‚   β”‚   └── mock/                   # Mock implementations for testing
β”‚   β”‚       β”œβ”€β”€ auth.go             # Mock authentication
β”‚   β”‚       └── translator.go       # Mock ID translator (file-backed YAML mappings)
β”‚   └── middleware/                 # HTTP middleware components
β”‚       β”œβ”€β”€ authorization.go        # JWT-based authorization
β”‚       └── request_id.go           # Request ID injection
β”œβ”€β”€ pkg/                            # Public packages
β”‚   β”œβ”€β”€ constants/                  # Application constants
β”‚   β”‚   β”œβ”€β”€ context.go              # Context keys
β”‚   β”‚   β”œβ”€β”€ global.go               # Global constants
β”‚   β”‚   β”œβ”€β”€ storage.go              # Storage bucket names
β”‚   β”‚   └── subjects.go             # NATS subject definitions
β”‚   β”œβ”€β”€ errors/                     # Error types
β”‚   └── auth/                       # Auth0 token source helpers
β”œβ”€β”€ Dockerfile                      # Container build configuration
β”œβ”€β”€ Makefile                        # Build and development commands
β”œβ”€β”€ CLAUDE.md                       # Claude Code assistant instructions
└── go.mod                          # Go module definition

Committee–Mailing List Sync

This service does not implement committee-to-mailing-list member synchronization. That sync is fully handled by the system this service proxies to (the ITX/v1 backend).

The sync logic works as follows:

  • When a mailing list is created with committees configured, all matching members from each committee are immediately synced into the new list.
  • When a mailing list is updated, the service compares the old and new committee configurations and acts on three types of changes:
    • Added committee: the committee's members are fully synced into the list.
    • Removed committee: all committee-type members from that committee are removed from the list.
    • Modified committee: if the AllowedVotingStatuses filters changed, members who no longer match are removed and members who now match are added.

Because this service reuses the same database and infrastructure as the proxied backend, this sync loop is already closed and no additional implementation is needed here.

Committee Member Sync

  • When a committee member is added, the member is subscribed to all linked mailing lists they are eligible for based on the list's voting status filters.
  • When a committee member is removed, the member is unsubscribed from all private mailing lists linked to that committee. Public lists are not affected.
  • When a committee is deleted, its association with linked mailing lists is cleared. Existing members are left as-is β€” no one is removed.
  • When a committee association or its filters are updated on a mailing list, the membership is reconciled: members who now match are added, and members who no longer match are removed (private lists only).

Because this service reuses the same database and infrastructure as the proxied backend, this sync loop is already closed and no additional implementation is needed here.


πŸ“š Additional Documentation

DocumentDescription
docs/api-endpoints.mdFull list of API endpoints with method, path, and curl examples
docs/event-processing.mdv1β†’v2 data stream: how DynamoDB change events are consumed, transformed, and published to the indexer and FGA-sync services
docs/fga-contract.mdAuthoritative reference for all FGA sync messages (NATS subjects, payloads, and trigger conditions)

πŸ› οΈ Development

Prerequisites

  • Go 1.24+
  • Make
  • Git

Getting Started

  1. Install Dependencies

    make deps
    

    This installs:

    • Go module dependencies
    • Goa CLI for code generation
  2. Generate API Code

    make apigen
    

    Generates HTTP transport, client, and OpenAPI documentation from design files.

  3. Build the Application

    make build
    

    Creates the binary in bin/lfx-v2-mailing-list-service.

Development Workflow

Running the Service

# Run with auto-regeneration
make run

# Build and run binary
make build
./bin/lfx-v2-mailing-list-service

Code Quality

Always run these before committing:

# Run linter
make lint

# Run all tests
make test

# Run complete pipeline (setup + lint + test + build)
make all

Testing

# Run all tests with race detection and coverage
make test

# View coverage report
go tool cover -html=coverage.out

Writing Tests:

  • Place test files alongside source files with _test.go suffix
  • Use table-driven tests for multiple test cases
  • Mock external dependencies using the provided mock interfaces in internal/infrastructure/mock/
  • Achieve high test coverage (aim for >80%)
  • Test both happy path and error cases

Example test structure:

func TestServiceMethod(t *testing.T) {
    tests := []struct {
        name        string
        input       InputType
        setupMocks  func(*MockRepository)
        expected    ExpectedType
        expectError bool
    }{
        // Test cases here
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            // Test implementation
        })
    }
}

API Development

When modifying the API:

  1. Update Design Files in cmd/mailing-list-api/design/ directory

  2. Regenerate Code:

    make apigen
    
  3. Run Tests to ensure nothing breaks:

    make test
    
  4. Update Service Implementation in cmd/mailing-list-api/service/

ITX Proxy Architecture

All GroupsIO operations are delegated to the ITX HTTP API. The proxy layer handles Auth0 M2M token acquisition and transparent v2 UUID β†’ v1 SFID translation.

Authentication:

// ITX proxy uses Auth0 private-key JWT assertion with token caching
tokenSource := pkgauth.NewAuth0TokenSource(ctx, authConfig, config.Audience, itxScope)
oauthHTTPClient := oauth2.NewClient(ctx, oauth2.ReuseTokenSource(nil, tokenSource))

ID Translation:

// Orchestrators translate v2 UUIDs to v1 SFIDs before forwarding to ITX
sfid, err := translator.MapID(ctx, constants.TranslationSubjectProject,
    constants.TranslationDirectionV2ToV1, projectUID)

Configuration Modes:

  • Production: TRANSLATOR_SOURCE=nats β€” translates via NATS request/reply to the v1-sync-helper
  • Testing: TRANSLATOR_SOURCE=mock β€” loads mappings from a local YAML file (TRANSLATOR_MAPPINGS_FILE)

Available Make Targets

TargetDescription
make allComplete build pipeline (setup, lint, test, build)
make depsInstall dependencies and Goa CLI
make setupSetup development environment
make setup-devInstall development tools (golangci-lint)
make apigenGenerate API code from design files
make buildBuild the binary
make runRun the service locally
make testRun unit tests with race detection
make lintRun code linter
make cleanRemove build artifacts
make docker-buildBuild Docker image
make docker-runRun Docker container locally
make helm-installInstall Helm chart
make helm-install-localInstall with mock authentication
make helm-templatesPrint Helm templates
make helm-uninstallUninstall Helm chart

πŸ§ͺ Testing

Running Tests

# Run all tests
make test

# Run specific package tests
go test -v ./internal/service/...

# Run with coverage
go test -v -race -coverprofile=coverage.out ./...
go tool cover -html=coverage.out

Test Structure

The project follows Go testing best practices:

  • Unit Tests: Test individual components in isolation
  • Integration Tests: Test component interactions
  • Mock Interfaces: Located in internal/infrastructure/mock/
  • Test Coverage: Aim for high coverage with meaningful tests

Writing Tests

When adding new functionality:

  1. Write tests first (TDD approach recommended)
  2. Use table-driven tests for multiple scenarios
  3. Mock external dependencies using provided interfaces
  4. Test error conditions not just happy paths
  5. Keep tests focused and independent

Local Testing with Mock Authentication

For comprehensive integration testing using local Kubernetes cluster:

  1. Deploy with Mock Authentication:

    make helm-install-local
    

    This deploys the service with:

    • AUTH_SOURCE=mock - Bypasses JWT validation
    • JWT_AUTH_DISABLED_MOCK_LOCAL_PRINCIPAL=test-super-admin - Mock principal
    • TRANSLATOR_SOURCE=mock - File-backed ID mappings
  2. Test Individual Endpoints:

    # Any Bearer token works with mock auth
    curl -H "Authorization: Bearer test-token" \
         http://lfx-v2-mailing-list-service.lfx.svc.cluster.local:8080/groupsio/services
    

⚠️ Security Warning: Never use mock authentication in production environments.

πŸš€ Deployment

Kubernetes Secret

Before deploying, create the Kubernetes secret with ITX credentials. The command below is idempotent and safe to re-run (e.g. for credential rotation):

kubectl create secret generic lfx-v2-mailing-list-service -n lfx \
  --from-literal=ITX_CLIENT_ID="<value-from-1password>" \
  --from-literal=ITX_CLIENT_PRIVATE_KEY="<value-from-1password>" \
  --from-literal=ITX_AUTH0_DOMAIN="<value-from-1password>" \
  --from-literal=ITX_AUDIENCE="<value-from-1password>" \
  --from-literal=ITX_BASE_URL="<value-from-1password>" \
  --dry-run=client -o yaml | kubectl apply -f -

Where to find the secret values: Look in 1Password under the LFX V2 vault, in the secured note titled LFX Platform Chart Values Secrets - Local Development.

Helm Chart

The service includes a Helm chart for Kubernetes deployment:

# Install using make (recommended)
make helm-install

# Install with local values override using make
make helm-install-local

# Install directly with helm
helm upgrade --install lfx-v2-mailing-list-service ./charts/lfx-v2-mailing-list-service \
  --namespace lfx \
  --create-namespace

# Install with local values override directly
helm upgrade --install lfx-v2-mailing-list-service ./charts/lfx-v2-mailing-list-service \
  --namespace lfx \
  --create-namespace \
  --values ./charts/lfx-v2-mailing-list-service/values.local.yaml

# View rendered templates
make helm-templates

Docker

# Build Docker image
make docker-build

# Run with Docker
docker run -p 8080:8080 linuxfoundation/lfx-v2-mailing-list-service:latest

πŸ“‘ NATS Messaging

NATS serves two roles in this service: ID translation and event publishing.

ID Translation

The service uses NATS request/reply to translate v2 UUIDs to v1 SFIDs (and vice versa) via the v1-sync-helper service:

SubjectPurpose
lfx.lookup_v1_mappingTranslate project/committee UIDs ↔ SFIDs

Key format sent to the v1-sync-helper:

  • project.uid.<uuid> β€” v2 UUID β†’ v1 SFID
  • project.sfid.<sfid> β€” v1 SFID β†’ v2 UUID
  • committee.uid.<uuid> β€” v2 UUID β†’ v1 SFID (response: projectSFID:committeeSFID)

Published Subjects

The service publishes messages to the following NATS subjects (primarily via the v1β†’v2 data stream processor):

SubjectPurposeMessage Schema
lfx.index.groupsio_serviceGroupsIO service indexing eventsIndexer message with tags
lfx.index.groupsio_mailing_listMailing list indexing eventsIndexer message with tags
lfx.index.groupsio_memberMember indexing eventsIndexer message with tags
lfx.fga-sync.update_accessService and mailing list access control create/updateGeneric FGA message (update_access)
lfx.fga-sync.delete_accessService and mailing list access control deleteGeneric FGA message (delete_access)
lfx.fga-sync.member_putAdd member to mailing list in FGAGeneric FGA message (member_put)
lfx.fga-sync.member_removeRemove member from mailing list in FGAGeneric FGA message (member_remove)

Message Publisher Interface

The service uses two message types:

  • Indexer Messages: For search indexing operations (consumed by indexer services)
  • Access Messages: For permission management (consumed by fga-sync service)

πŸ“– API Documentation

The service automatically generates OpenAPI documentation:

  • OpenAPI 2.0: gen/http/openapi.yaml
  • OpenAPI 3.0: gen/http/openapi3.yaml
  • JSON formats: Also available in gen/http/

Access the documentation at: http://localhost:8080/openapi.json

Available Endpoints

The full list of available endpoints is documented via Swagger. Access the live spec at:

  • http://localhost:8080/openapi.json (JSON)
  • http://localhost:8080/openapi3.yaml (YAML)

πŸ”§ Configuration

The service can be configured via environment variables:

Core Service Configuration

VariableDescriptionDefault
NATS_URLNATS server URLnats://lfx-platform-nats.lfx.svc.cluster.local:4222
NATS_TIMEOUTNATS connection timeout10s
NATS_MAX_RECONNECTMaximum NATS reconnect attempts3
NATS_RECONNECT_WAITWait between NATS reconnect attempts2s
LOG_LEVELLog level (debug, info, warn, error)info
LOG_ADD_SOURCEAdd source location to logstrue
PORTHTTP server port8080

Authentication Configuration

VariableDescriptionDefault
JWKS_URLJWKS URL for JWT verificationhttp://lfx-platform-heimdall.lfx.svc.cluster.local:4457/.well-known/jwks
JWT_AUDIENCEJWT token audiencelfx-v2-mailing-list-service
AUTH_SOURCEAuthentication source (jwt or mock)jwt
JWT_AUTH_DISABLED_MOCK_LOCAL_PRINCIPALMock principal for local dev (dev only)""

ITX Proxy Configuration

VariableDescriptionDefault
ITX_BASE_URLITX HTTP API base URLRequired
ITX_CLIENT_IDAuth0 client ID for M2M authenticationRequired
ITX_CLIENT_PRIVATE_KEYRSA private key (PEM) for Auth0 JWT assertionRequired
ITX_AUTH0_DOMAINAuth0 tenant domainRequired
ITX_AUDIENCEAuth0 audience for the ITX APIRequired

Where to find ITX_CLIENT_ID and ITX_CLIENT_PRIVATE_KEY: Look in 1Password under the LFX V2 vault, in the secure note LFX Platform Chart Values Secrets - Local Development.

ID Translator Configuration

VariableDescriptionDefault
TRANSLATOR_SOURCETranslator backend (nats or mock)nats
TRANSLATOR_MAPPINGS_FILEYAML file for mock translator mappingstranslator_mappings.yaml

Development Environment Variables

For local development with mock backends (no real ITX or NATS required):

export AUTH_SOURCE="mock"
export JWT_AUTH_DISABLED_MOCK_LOCAL_PRINCIPAL="test-admin"
export TRANSLATOR_SOURCE="mock"
export TRANSLATOR_MAPPINGS_FILE="translator_mappings.yaml"
export LOG_LEVEL="debug"

For local development with real NATS but mock auth:

export NATS_URL="nats://localhost:4222"
export AUTH_SOURCE="mock"
export JWT_AUTH_DISABLED_MOCK_LOCAL_PRINCIPAL="test-admin"
export TRANSLATOR_SOURCE="nats"
export ITX_BASE_URL="https://api.dev.itx.linuxfoundation.org"
export ITX_CLIENT_ID="your-client-id"
export ITX_CLIENT_PRIVATE_KEY="$(cat tmp/local.private.key)"
export ITX_AUTH0_DOMAIN="linuxfoundation-dev.auth0.com"
export ITX_AUDIENCE="https://api.dev.itx.linuxfoundation.org/"
export LOG_LEVEL="debug"

πŸ“„ License

Copyright The Linux Foundation and each contributor to LFX.

SPDX-License-Identifier: MIT