1099 lines
41 KiB
Markdown
1099 lines
41 KiB
Markdown
# go-caatsm
|
||
|
||
Civil Aviation Authority Telegram Message Processor
|
||
|
||
A high-performance, production-ready message processing system for aviation telegrams using Clean Architecture, NATS JetStream, and PostgreSQL.
|
||
|
||
## Architecture
|
||
|
||
This project follows Clean Architecture principles with clear separation of concerns:
|
||
|
||
```
|
||
/cmd/main/main.go # Application entry point
|
||
/internal
|
||
/port # Port layer (interfaces/contracts)
|
||
repository.go # Repository interface
|
||
publisher.go # Publisher interface
|
||
/domain # Domain models (pure Go types, no external dependencies)
|
||
aviation.go # Aviation domain types (FPL, DEP, ARR, etc.)
|
||
/app # Application layer (business logic orchestration)
|
||
processor.go # Message processor
|
||
/adapter # Adapter layer (implementations)
|
||
/parser # Message parsing adapters
|
||
/mapper # Data mapping (domain ↔ infrastructure)
|
||
/dto # Data Transfer Objects
|
||
telegram.go # ParsedTelegram and MessageStatus
|
||
/infra # Infrastructure layer
|
||
/config # Configuration management (Koanf)
|
||
/nats # NATS JetStream client
|
||
/postgres # PostgreSQL repository (pgx)
|
||
/log # Logging (Zap)
|
||
/metrics # Prometheus metrics
|
||
/telemetry # OpenTelemetry tracing
|
||
/pkg/di # Dependency injection (Wire)
|
||
```
|
||
|
||
## Features
|
||
|
||
- **Clean Architecture**: Clear separation between domain, application, and infrastructure layers
|
||
- **NATS JetStream**: Reliable message streaming with automatic retries and dead-letter queues
|
||
- **TimescaleDB (PostgreSQL)**: High-performance persistence using pgx with batch operations and hypertables
|
||
- **Dependency Injection**: Google Wire for compile-time dependency injection
|
||
- **Configuration Management**: Koanf for flexible configuration loading (file + environment variables)
|
||
- **Structured Logging**: Zap logger with configurable levels and formats
|
||
- **Batch Processing**: Efficient batch message processing and database inserts
|
||
|
||
## Contributor Guide
|
||
|
||
For coding standards, test expectations, and release hygiene, read [AGENTS.md](AGENTS.md).
|
||
|
||
## Prerequisites
|
||
|
||
- Go 1.22+
|
||
- PostgreSQL 12+
|
||
- NATS Server with JetStream enabled
|
||
|
||
## Installation
|
||
|
||
1. Clone the repository:
|
||
```bash
|
||
git clone <repository-url>
|
||
cd go-caatsm
|
||
```
|
||
|
||
2. Install dependencies:
|
||
```bash
|
||
go mod download
|
||
```
|
||
|
||
3. Set up PostgreSQL database:
|
||
```bash
|
||
psql -U postgres -f internal/infra/postgres/telegrams.ddl
|
||
```
|
||
|
||
4. Configure the application:
|
||
- Copy `configs/config.dev.toml` and modify as needed
|
||
- Or set environment variables with `CAATSM_` prefix
|
||
|
||
## Configuration
|
||
|
||
Configuration is loaded from TOML files and environment variables. The configuration file should be located at `configs/config.{env}.toml` where `{env}` is determined by the `GO_ENV` environment variable (defaults to `dev`).
|
||
|
||
- `nats.url` and `nats.stream` are required (the latter defaults to `TELEGRAM` when omitted).
|
||
- `subscription.topic` is optional; when not provided the application subscribes to `telegram.>`.
|
||
|
||
### Configuration Structure
|
||
|
||
```toml
|
||
[nats]
|
||
url = "nats://localhost:4222"
|
||
# mode: "jetstream" (default) or "core"
|
||
# See "NATS Mode Selection" section below for detailed comparison
|
||
mode = "jetstream"
|
||
stream = "TELEGRAM"
|
||
consumer = "telegram-consumer"
|
||
client = "serial-client"
|
||
cluster = "tele-cluster"
|
||
|
||
[nats.stream_limits]
|
||
# These settings only apply when mode = "jetstream"
|
||
max_msgs = 100000
|
||
max_bytes = 67108864
|
||
max_age = "24h"
|
||
discard = "old"
|
||
storage = "file"
|
||
replicas = 1
|
||
|
||
[nats.consumer_rules]
|
||
# Consumer delivery rules (only applies when mode = "jetstream")
|
||
# max_deliver: Maximum number of delivery attempts before giving up
|
||
max_deliver = 3
|
||
# ack_wait: Time to wait for ACK before redelivering message
|
||
ack_wait = "30s"
|
||
# max_ack_pending: Maximum number of unacknowledged messages before pausing delivery
|
||
max_ack_pending = 1000
|
||
|
||
[subscription]
|
||
# Optional. Defaults to "telegram.>" when omitted.
|
||
topic = "telegram.serial"
|
||
# queue_group: Used in both core and jetstream modes for load balancing
|
||
queue_group = "tele-queue"
|
||
|
||
[publisher]
|
||
topic = "telegram.json"
|
||
|
||
[postgres]
|
||
url = "postgres://user:password@localhost:5432/aviation?sslmode=disable"
|
||
max_conns = 10
|
||
min_conns = 2
|
||
|
||
[app]
|
||
batch_size = 50
|
||
batch_timeout = "2s"
|
||
monitor_interval = "30s"
|
||
|
||
[log]
|
||
level = "info"
|
||
format = "json"
|
||
|
||
[telemetry]
|
||
enabled = false
|
||
endpoint = "http://otel-collector:4318"
|
||
insecure = true
|
||
|
||
# Production configuration example:
|
||
# enabled = true
|
||
# endpoint = "otel-collector.company.com:4318"
|
||
# insecure = false # Use TLS in production
|
||
|
||
### Timeouts and Ack Wait
|
||
|
||
`[timeouts]` is optional, but if you plan to tune JetStream redelivery you should set `timeouts.ack_wait` and/or `[nats.consumer].ack_wait`. When neither is specified the application defaults both values to `30s`, ensuring predictable redelivery timing.
|
||
```
|
||
|
||
### Environment Variables
|
||
|
||
You can override any configuration value using environment variables with the `CAATSM_` prefix:
|
||
|
||
```bash
|
||
export CAATSM_NATS_URL="nats://nats-server:4222"
|
||
export CAATSM_POSTGRES_URL="postgres://user:pass@db:5432/aviation"
|
||
export CAATSM_LOG_LEVEL="debug"
|
||
```
|
||
|
||
Environment variable names are converted from `CAATSM_NATS_URL` to `nats.url` in the configuration.
|
||
|
||
### NATS Mode Selection
|
||
|
||
The application supports two NATS consumption modes, controlled by `nats.mode`:
|
||
|
||
#### JetStream Mode (Recommended for Production)
|
||
|
||
**Configuration:** `nats.mode = "jetstream"` (default)
|
||
|
||
**Features:**
|
||
- ✅ **Message Persistence**: Messages are stored in a Stream, allowing replay and recovery
|
||
- ✅ **ACK/NAK Mechanism**: Explicit message acknowledgment ensures guaranteed delivery
|
||
- ✅ **Error Handling**: Failed messages are handled with simple backoff
|
||
- ✅ **Dead-Letter Queue**: Poison messages can be routed to a DLQ for inspection
|
||
- ✅ **Batch Processing**: Efficient batch fetching and processing
|
||
- ✅ **Consumer Monitoring**: Real-time metrics for consumer lag and pending messages
|
||
- ✅ **At-Least-Once Delivery**: Messages are guaranteed to be delivered at least once
|
||
|
||
**Use Cases:**
|
||
- Production environments requiring message reliability
|
||
- Scenarios where message loss is unacceptable
|
||
- Systems needing message replay capabilities
|
||
- Applications requiring retry logic for transient failures
|
||
|
||
**Configuration Requirements:**
|
||
- Requires JetStream to be enabled on the NATS server
|
||
- Stream must be created (auto-created in dev/test environments)
|
||
- Consumer configuration via `[nats.consumer_rules]` section
|
||
|
||
**How to Use JetStream Mode:**
|
||
|
||
1. **Prerequisites:**
|
||
- Ensure NATS server has JetStream enabled (default in `docker-compose.dev.yml`)
|
||
- Set `nats.mode = "jetstream"` in your config file (or use `CAATSM_NATS_MODE=jetstream`)
|
||
|
||
2. **Start NATS with JetStream:**
|
||
```bash
|
||
# Using Docker Compose (recommended for development)
|
||
docker compose -f docker-compose.dev.yml up -d nats
|
||
|
||
# Or start NATS server manually with JetStream enabled:
|
||
# nats-server -js
|
||
```
|
||
|
||
3. **Configure Stream and Consumer:**
|
||
The application automatically creates the Stream and Consumer on startup in dev/test environments (`GO_ENV=dev` or `GO_ENV=test`). In production, you may need to create them manually or ensure they exist.
|
||
|
||
**Stream Configuration** (`[nats.stream_limits]`):
|
||
- `max_msgs`: Maximum number of messages in the stream (default: 100000)
|
||
- `max_bytes`: Maximum total size of messages (default: 64MB)
|
||
- `max_age`: Maximum age of messages before deletion (default: 24h)
|
||
- `storage`: "file" (persistent) or "memory" (ephemeral)
|
||
- `replicas`: Number of stream replicas for HA (default: 1, use 3+ for production)
|
||
|
||
**Consumer Configuration** (`[nats.consumer_rules]`):
|
||
- `max_deliver`: Maximum delivery attempts before giving up (default: 3)
|
||
- `ack_wait`: Time to wait for ACK before redelivery (default: 30s)
|
||
|
||
4. **Start the Application:**
|
||
```bash
|
||
# Development mode (auto-creates stream/consumer)
|
||
GO_ENV=dev \
|
||
CAATSM_NATS_MODE=jetstream \
|
||
CAATSM_POSTGRES_URL=postgres://user:pass@localhost:5432/aviation \
|
||
go run ./cmd/main listen
|
||
|
||
# Production mode (requires stream/consumer to exist)
|
||
GO_ENV=prod \
|
||
CAATSM_NATS_MODE=jetstream \
|
||
./bin/receiver listen
|
||
```
|
||
|
||
5. **Publish Messages to JetStream:**
|
||
```bash
|
||
# Using nats-box (included in docker-compose.dev.yml)
|
||
docker compose exec nats-box nats pub telegram.serial "ZCZC TEST123 150631..."
|
||
|
||
# Or use the seed-telegrams tool with JetStream
|
||
go run ./cmd/seed-telegrams \
|
||
--nats-url nats://localhost:4222 \
|
||
--jetstream \
|
||
--stream TELEGRAM \
|
||
--js-subject telegram.serial \
|
||
--count 10
|
||
```
|
||
|
||
6. **Monitor JetStream:**
|
||
```bash
|
||
# View stream info
|
||
docker compose exec nats-box nats stream info TELEGRAM
|
||
|
||
# View consumer info
|
||
docker compose exec nats-box nats consumer info TELEGRAM telegram-consumer
|
||
|
||
# View pending messages
|
||
docker compose exec nats-box nats consumer next TELEGRAM telegram-consumer
|
||
|
||
# Or use NATS monitoring UI at http://localhost:8222
|
||
```
|
||
|
||
7. **Message Processing Flow:**
|
||
- Messages are published to the configured subject (e.g., `telegram.serial`)
|
||
- Stream stores messages according to retention policy
|
||
- Consumer pulls messages in batches (configurable via `app.batch_size`)
|
||
- Each message is processed and ACKed on success
|
||
- Failed messages are NAKed and redelivered with simple backoff
|
||
- After `max_deliver` attempts, permanent failures are routed to DLQ (if enabled)
|
||
|
||
8. **Replay Messages:**
|
||
```bash
|
||
# Replay from a specific sequence
|
||
./bin/receiver listen --replay-from seq:12345
|
||
|
||
# Replay from a specific time
|
||
./bin/receiver listen --replay-from time:2024-11-15T08:00:00Z
|
||
```
|
||
|
||
9. **Dead-Letter Queue (DLQ):**
|
||
Enable DLQ in config to route poison messages:
|
||
```toml
|
||
[dlq]
|
||
enabled = true
|
||
subject = "caatsm.dlq"
|
||
```
|
||
Messages that fail after `max_deliver` attempts are published to the DLQ subject for manual inspection.
|
||
|
||
10. **Troubleshooting:**
|
||
- **Stream not found**: Ensure `GO_ENV=dev` for auto-creation, or create manually in production
|
||
- **Consumer not found**: Application auto-creates consumer on startup
|
||
- **Messages not being consumed**: Check consumer info for pending messages and delivery status
|
||
- **High pending count**: Increase `batch_size` or add more consumer instances
|
||
- **Messages being redelivered**: Check processing logs for errors; adjust `ack_wait` if processing takes longer
|
||
|
||
#### Core NATS Mode (Default for Development)
|
||
|
||
**Configuration:** `nats.mode = "core"` (default in `config.dev.toml`)
|
||
|
||
**Features:**
|
||
- ⚡ **Simple Pub/Sub**: Basic publish/subscribe messaging
|
||
- ⚡ **Queue Groups**: Load balancing across multiple consumers
|
||
- ⚡ **Low Latency**: No persistence overhead
|
||
- ⚡ **Fast Startup**: No stream/consumer setup required
|
||
- ❌ **No Persistence**: Messages are lost if no consumer is available
|
||
- ❌ **No ACK**: No delivery guarantees
|
||
- ❌ **No Retry**: Processing failures are logged but not retried
|
||
- ❌ **No DLQ**: Failed messages cannot be routed to a dead-letter queue
|
||
|
||
**Use Cases:**
|
||
- **Local development** (recommended default)
|
||
- Quick testing and iteration
|
||
- Real-time monitoring/logging where message loss is acceptable
|
||
- Simple pub/sub scenarios without reliability requirements
|
||
- Performance testing without persistence overhead
|
||
|
||
**Configuration Requirements:**
|
||
- Works with any NATS server (JetStream not required)
|
||
- Only `[subscription]` settings are used (queue_group for load balancing)
|
||
- `[nats.consumer_rules]` and `[nats.stream_limits]` are ignored
|
||
|
||
**How to Use Core Mode:**
|
||
|
||
1. **Start NATS Server** (JetStream not required, but can be enabled):
|
||
```bash
|
||
# Simple NATS server
|
||
nats-server
|
||
|
||
# Or with Docker Compose (JetStream enabled but not required for core mode)
|
||
docker compose -f docker-compose.dev.yml up -d nats
|
||
```
|
||
|
||
2. **Start the Application** (Core mode is default in dev config):
|
||
```bash
|
||
# Core mode is default, no need to specify
|
||
GO_ENV=dev \
|
||
CAATSM_POSTGRES_URL=postgres://user:pass@localhost:5432/aviation \
|
||
go run ./cmd/main listen
|
||
```
|
||
|
||
3. **Publish Messages** (use standard NATS publish):
|
||
```bash
|
||
# Using nats-box
|
||
docker compose exec nats-box nats pub telegram.serial "ZCZC TEST123 150631..."
|
||
|
||
# Or use seed-telegrams without --jetstream flag
|
||
go run ./cmd/seed-telegrams \
|
||
--nats-url nats://localhost:4222 \
|
||
--subject telegram.serial \
|
||
--count 10
|
||
```
|
||
|
||
**Switching Modes:**
|
||
|
||
```bash
|
||
# Use Core NATS mode (default for development)
|
||
CAATSM_NATS_MODE=core go run ./cmd/main listen
|
||
# Or simply (core is default in config.dev.toml)
|
||
go run ./cmd/main listen
|
||
|
||
# Use JetStream mode (for production or integration testing)
|
||
CAATSM_NATS_MODE=jetstream go run ./cmd/main listen
|
||
```
|
||
|
||
**Note:** The publisher always uses JetStream for deduplicated fan-out, regardless of the consumer mode. If you need pure Core NATS, ensure publishers also use Core NATS subjects.
|
||
|
||
## Usage
|
||
|
||
### Build
|
||
|
||
The build process automatically injects build information (version, commit, build time) into the binary. This information is available via the `/livez` and `/readyz` health endpoints.
|
||
|
||
Using Make (writes `bin/receiver`):
|
||
|
||
```bash
|
||
make build
|
||
# Or with custom version:
|
||
VERSION=v1.0.0 make build
|
||
```
|
||
|
||
Using Task:
|
||
|
||
```bash
|
||
task build
|
||
# Or with custom version:
|
||
VERSION=v1.0.0 task build
|
||
```
|
||
|
||
Or directly with Go:
|
||
|
||
```bash
|
||
# With build info injection:
|
||
go build -ldflags "-X 'caatsm/internal/infra/buildinfo.Version=dev' -X 'caatsm/internal/infra/buildinfo.Commit=$(git rev-parse --short HEAD)' -X 'caatsm/internal/infra/buildinfo.BuiltAt=$$(go run - <<'EOF'
|
||
package main
|
||
import (
|
||
\"fmt\"
|
||
\"time\"
|
||
)
|
||
func main() {
|
||
fmt.Print(time.Now().UTC().Format(time.RFC3339))
|
||
}
|
||
EOF)'" -o bin/receiver ./cmd/main
|
||
```
|
||
|
||
Build information is automatically populated from:
|
||
- **Version**: `VERSION` environment variable (defaults to "dev")
|
||
- **Commit**: Git commit hash (short format)
|
||
- **BuiltAt**: UTC timestamp of build time
|
||
|
||
### Run
|
||
|
||
#### Development Mode
|
||
|
||
Use Make targets (binary mode):
|
||
|
||
```bash
|
||
make run-dev # GO_ENV=dev (uses core NATS mode by default)
|
||
make run-local # go run ./cmd/main listen (honors GO_ENV)
|
||
```
|
||
|
||
Task equivalents:
|
||
|
||
```bash
|
||
task run-dev
|
||
task run-local # go run ./cmd/main listen
|
||
task dev-run # boots docker-compose dev stack + go run (core NATS mode)
|
||
```
|
||
|
||
#### Production Mode
|
||
|
||
For production deployment, see the comprehensive guide: **[Production Deployment Guide](docs/prod-guide.md)**
|
||
|
||
Quick start:
|
||
|
||
```bash
|
||
# Build the binary with version information
|
||
VERSION=v1.0.0 make build
|
||
|
||
# Run in production mode
|
||
make run-prod # GO_ENV=prod (requires config.prod.toml)
|
||
```
|
||
|
||
**Key requirements:**
|
||
- JetStream mode (mandatory)
|
||
- Stream and Consumer must be created manually
|
||
- Production configuration file: `configs/config.prod.toml`
|
||
- SSL/TLS for secure connections
|
||
- NATS authentication configured (see `docs/prod-guide.md#nats-authentication`)
|
||
|
||
See `docs/prod-guide.md` for complete production deployment instructions, including:
|
||
- NATS authentication setup
|
||
- Database migrations (see `docs/migrations.md`)
|
||
- Secret management (see `docs/secret-management.md`)
|
||
- Performance tuning (see `docs/performance.md`)
|
||
|
||
### Command Line Options
|
||
|
||
```bash
|
||
./bin/receiver listen --help
|
||
|
||
Flags:
|
||
-n, --nats-url string NATS server address
|
||
-t, --subject string NATS subject to listen to
|
||
--stream string JetStream stream name
|
||
--consumer string JetStream durable consumer
|
||
--publisher-topic string Subject used by the publisher
|
||
--postgres-url string PostgreSQL connection URL
|
||
--log-level string Logger level (debug|info|warn|error)
|
||
--replay-from string Deliver policy override (all|new|last|seq:<n>|time:<RFC3339>)
|
||
--ack-wait duration Ack wait override (e.g. 45s)
|
||
--telemetry-enabled Enable OpenTelemetry exporters
|
||
--telemetry-endpoint string
|
||
OTLP collector endpoint
|
||
--telemetry-insecure Send OTLP traffic without TLS
|
||
```
|
||
|
||
Critical overrides stay available through CLI flags; configuration is managed via the TOML file or `CAATSM_` environment variables.
|
||
|
||
| CLI flag | Config key | Purpose |
|
||
|---------------------|------------------------|----------------------------------------|
|
||
| `--nats-url` | `nats.url` | Point to a different NATS cluster |
|
||
| `--subject` | `subscription.topic` | Change the subscribed subject filter |
|
||
| `--stream` | `nats.stream` | Bind to another JetStream stream |
|
||
| `--consumer` | `nats.consumer` | Override the durable consumer name |
|
||
| `--publisher-topic` | `publisher.topic` | Publish parsed output to a new subject |
|
||
| `--postgres-url` | `postgres.url` | Redirect persistence to another DB |
|
||
| `--log-level` | `log.level` | Adjust runtime logging verbosity |
|
||
| `--telemetry-*` | `telemetry.*` | Toggle tracing/metrics exporters |
|
||
|
||
#### Replay & Backoff
|
||
|
||
- `--replay-from seq:12345` replays from a specific JetStream sequence, while `--replay-from time:2024-11-15T08:00:00Z` starts at a timestamp.
|
||
- Configure retry behavior with `[nats.consumer_rules]` settings.
|
||
|
||
### Observability
|
||
|
||
The processor exposes three complementary observability surfaces with production-ready OpenTelemetry implementation:
|
||
|
||
1. **OpenTelemetry (traces + metrics)**
|
||
- **Production-ready setup** with environment-based sampling, comprehensive resource attributes, and optimized batching.
|
||
- Enable via `[telemetry] enabled = true` and set `endpoint` to your OTLP/HTTP collector (e.g., `http://otel-collector:4318`).
|
||
- **Sampling strategy**:
|
||
- Production: 1% sampling (cost-effective)
|
||
- Staging: 10% sampling (balanced observability)
|
||
- Development/Test: 100% sampling (full debugging)
|
||
- CLI overrides:
|
||
- `--telemetry-enabled` toggles exporters on/off.
|
||
- `--telemetry-endpoint` and `--telemetry-insecure` adjust the OTLP HTTP endpoint and TLS behavior.
|
||
- **Comprehensive traces** with semantic attributes:
|
||
- `caatsm/app`: Message processing spans with `messaging.system`, `messaging.operation`, `caatsm.message.category`
|
||
- `caatsm/postgres`: Database operations with `db.system`, `db.operation`, `db.table`
|
||
- `caatsm/nats`: NATS operations with `messaging.destination`, `messaging.consumer.id`
|
||
- **Business metrics** (focused set for OTEL):
|
||
- `caatsm_messages_processed_total` (counter, by `message.status` / `message.category`)
|
||
- `caatsm_publish_failures_total` (counter)
|
||
- `caatsm_parse_duration_seconds` (histogram)
|
||
- **Resource attributes** include service metadata, environment, build info, and infrastructure details.
|
||
- Application code records telemetry via a thin `telemetry.Recorder` abstraction, which fans out to OTEL and Prometheus backends as configured.
|
||
|
||
2. **Prometheus metrics (`/metrics`)**
|
||
- Implemented in `internal/infra/metrics` and considered the primary source for SRE PromQL/SLOs.
|
||
- Key metric families:
|
||
- `caatsm_messages_total{stream,consumer,result}` – per-stream/consumer throughput and results.
|
||
- `caatsm_handle_latency_seconds_bucket{stream,consumer}` – end-to-end handling latency from NATS receive to handler completion.
|
||
- `caatsm_retries_total{stream,consumer,reason}` – JetStream retry/NAK counts.
|
||
- `caatsm_db_queries_total{operation,result}` and `caatsm_db_query_latency_seconds_bucket{operation}` – DB activity and latency.
|
||
- `caatsm_dlq_messages_total{stream,consumer}` and `caatsm_dlq_publish_failures_total{stream,consumer}` – DLQ routing success/failures.
|
||
- `caatsm_nats_consumer_pending_messages{stream,consumer}` – JetStream consumer backlog/lag.
|
||
- Prometheus scrapes `GET /metrics` on the monitoring server; Grafana dashboards under `configs/grafana-dashboards.dev` are wired to these series.
|
||
|
||
3. **Health and readiness endpoints**
|
||
- A lightweight monitoring server exposes:
|
||
- `GET /livez` – liveness endpoint: reports process and build information, does not call external dependencies.
|
||
- `GET /readyz` – readiness endpoint: pings PostgreSQL and checks NATS connection status within `monitoring.health_timeout`, returning 503 on failure.
|
||
- `GET /healthz` – backward-compatible alias currently sharing logic with `/readyz`.
|
||
- Responses include build metadata and dependency status/latency (see `docs/observability.md` for examples).
|
||
- Configure the server via the `[monitoring]` block (defaults shown):
|
||
|
||
```toml
|
||
[monitoring]
|
||
addr = ":2112"
|
||
enable_metrics = true
|
||
enable_health = true
|
||
read_timeout = "5s"
|
||
write_timeout = "5s"
|
||
health_timeout = "2s"
|
||
```
|
||
|
||
Set `monitoring.disabled = true` (or `addr = ""`) if you need to turn the HTTP server off, e.g., during certain integration tests.
|
||
|
||
## Development
|
||
|
||
See `docs/dev-guide.md` for the full development workflow, including Docker Compose instructions, observability tooling, and troubleshooting tips.
|
||
|
||
Quick start:
|
||
|
||
```bash
|
||
# Start database + messaging
|
||
docker compose -f docker-compose.dev.yml up -d postgres nats nats-box
|
||
|
||
# Start observability stack (optional)
|
||
docker compose -f docker-compose.dev.yml up -d otel-collector jaeger prometheus grafana
|
||
```
|
||
|
||
Run the processor locally while the infra runs in Docker:
|
||
|
||
```bash
|
||
# Core NATS mode (default for development, fast and lightweight)
|
||
GO_ENV=dev \
|
||
CAATSM_POSTGRES_URL=postgres://caatsm:caatsm@localhost:5432/aviation?sslmode=disable \
|
||
go run ./cmd/main listen
|
||
|
||
# JetStream mode (for integration testing or production-like behavior)
|
||
GO_ENV=dev \
|
||
CAATSM_NATS_MODE=jetstream \
|
||
CAATSM_POSTGRES_URL=postgres://caatsm:caatsm@localhost:5432/aviation?sslmode=disable \
|
||
go run ./cmd/main listen
|
||
```
|
||
|
||
Tear everything down with `docker compose -f docker-compose.dev.yml down -v`.
|
||
|
||
## Deployment Examples
|
||
|
||
For production deployment, see the comprehensive guide: **[Production Deployment Guide](docs/prod-guide.md)**
|
||
|
||
Additional deployment-specific guides:
|
||
|
||
- **`docs/prod-guide.md`** - Complete production deployment guide with configuration, setup, and operations
|
||
- **`docs/deploy-systemd.md`** - Systemd service deployment with environment file configuration
|
||
- **`docs/deploy-k8s.md`** - Kubernetes deployment with ConfigMap/Secret and health probes
|
||
|
||
## Additional Documentation
|
||
|
||
- **`docs/migrations.md`** - Database migration strategy and best practices
|
||
- **`docs/secret-management.md`** - Secret management best practices and integration guides
|
||
- **`docs/performance.md`** - Performance tuning guidelines and optimization strategies
|
||
- **`docs/observability.md`** - Observability setup and metrics documentation
|
||
- **`docs/nats.md`** - NATS/JetStream configuration and usage guide
|
||
- **`docs/reliability.md`** - Reliability patterns and error handling
|
||
|
||
### Project Structure
|
||
|
||
- **Domain Layer** (`internal/domain`): Pure business logic and domain models
|
||
- **Application Layer** (`internal/app`): Orchestrates business flows
|
||
- **Adapter Layer** (`internal/adapter`): Interfaces and adapters between layers
|
||
- **Infrastructure Layer** (`internal/infra`): External concerns (NATS, PostgreSQL, config, logging)
|
||
|
||
### Adding New Features
|
||
|
||
1. **Domain Changes**: Add to `internal/domain` (no external dependencies)
|
||
2. **Business Logic**: Add to `internal/app`
|
||
3. **External Integrations**: Add to `internal/infra`
|
||
4. **Adapters**: Add to `internal/adapter` to bridge between layers
|
||
|
||
### Dependency Injection
|
||
|
||
Dependencies are managed using Google Wire. To add a new dependency:
|
||
|
||
1. Create a provider function in the appropriate package
|
||
2. Add it to `pkg/di/wire.go`
|
||
3. Run `wire ./pkg/di` to regenerate `wire_gen.go`
|
||
|
||
> If the `wire` binary is missing, install it with `go install github.com/google/wire/cmd/wire@v0.7.0` and ensure `$GOPATH/bin` is on your `PATH` (or run it directly via the absolute path).
|
||
|
||
### Testing
|
||
|
||
The project keeps tests close to the code that they exercise:
|
||
|
||
- **Domain/adapter/app unit tests** live under `internal/**` and cover parsing, validation, orchestration, and adapters. Run them all with `task test` (or `make test`), which now uses the Ginkgo CLI to run unit test suites in verbose mode (`ginkgo -r -v ./cmd ./internal`).
|
||
- **Integration tests** under `test/integration` spin up disposable TimescaleDB and NATS JetStream instances (via `testcontainers-go`) and execute a full ingestion flow. Use `task test-int` after ensuring Docker is running.
|
||
- **Coverage goals** are tracked via `task coverage`, which produces both a coverage profile and an HTML report under `coverage/coverage.html`.
|
||
- **Benchmark tests** are available for performance-critical components:
|
||
```bash
|
||
# Run parser benchmarks
|
||
go test -bench=BenchmarkParse -benchmem ./internal/adapter/parser
|
||
|
||
# Run repository benchmarks (requires DB connection)
|
||
go test -bench=BenchmarkMapper -benchmem ./internal/infra/postgres
|
||
|
||
# Run processor benchmarks
|
||
go test -bench=BenchmarkHandle -benchmem ./internal/app
|
||
```
|
||
|
||
| Purpose | Make command | Task command |
|
||
|----------------------------|---------------------|---------------------|
|
||
| Run unit tests (Ginkgo) | `make test` | `task test` |
|
||
| Run integration tests | `make test-int` | `task test-int` |
|
||
| Run unit+integration tests | `make test-all` | `task test-all` |
|
||
| Generate coverage html | `make coverage` | `task coverage` |
|
||
| Lint (golangci-lint) | `make lint` | `task lint` |
|
||
|
||
> Integration tests need Docker available on the host. Ginkgo-based unit tests or lint targets require the respective binaries (`go install github.com/onsi/ginkgo/v2/ginkgo@latest`, [golangci-lint install guide](https://golangci-lint.run/)). Use `task install-test` to bootstrap Ginkgo tooling before running `task test`, `task test-all`, or their `make` equivalents. `make test` / `task test` run Ginkgo in verbose mode (`-v`) over `./cmd` and `./internal`, showing each spec for easier debugging.
|
||
|
||
## Message Flow
|
||
|
||
1. **NATS Consumer** receives raw telegram messages from NATS:
|
||
- **JetStream mode** (default): Uses durable pull consumer with batch processing, ACK/NAK, and retry logic
|
||
- **Core mode**: Uses `QueueSubscribe` for simple pub/sub with queue group load balancing (no persistence or retries)
|
||
2. **MessageProcessor** orchestrates the processing:
|
||
- Parses the message using the Parser adapter
|
||
- Stores the parsed message in PostgreSQL via Repository
|
||
- Publishes the parsed message to the output topic via Publisher
|
||
3. **ACK/NAK** is sent based on processing success/failure
|
||
4. **Retry Logic** handles transient failures automatically
|
||
|
||
### Error Handling & Retries
|
||
|
||
- **Parser failures** (invalid headers/body) are treated as permanent: the raw payload is stored in `aviation.telegrams_raw`, the message is ACKed, and no JetStream retries are attempted.
|
||
- **Repository failures** are transient: the consumer returns an error, the message is `NAK`ed, and JetStream redelivers it with simple backoff.
|
||
- **Publisher failures** are logged and persisted as raw records, but they are marked permanent to avoid hammering downstream topics; the deduplicated output can be replayed from the raw table later.
|
||
- Tune JetStream retry behavior via `[nats.consumer_rules.max_deliver]`, `[nats.consumer_rules.backoff]`, and CLI overrides like `--ack-wait`. The monitoring server plus Prometheus counters provide visibility into each failure bucket.
|
||
|
||
### Failure Buckets
|
||
|
||
Messages that cannot be parsed or fail to publish are written to `aviation.telegrams_raw` with a status:
|
||
|
||
| Status | Description |
|
||
|-----------------------|--------------------------------------------------|
|
||
| `parsed` | Successfully parsed and stored |
|
||
| `header_error` | Header invalid (missing start indicator, etc.) |
|
||
| `body_error` | Body pattern did not match any known format |
|
||
| `publish_error` | Downstream publisher returned an error |
|
||
|
||
Each entry stores the raw payload, received timestamp, and metadata to aid replay or manual inspection.
|
||
|
||
## Message Parsing
|
||
|
||
The system supports parsing of aviation telegram messages in the standard ICAO format. All messages follow a common header structure, followed by a message body that varies by message type.
|
||
|
||
### Message Format
|
||
|
||
All telegrams follow this general structure:
|
||
|
||
```
|
||
ZCZC <MessageID> <DateTime>
|
||
<PriorityIndicator> <PrimaryAddress>
|
||
<SecondaryAddresses>
|
||
<Originator>
|
||
<Body>
|
||
NNNN
|
||
```
|
||
|
||
**Header Fields:**
|
||
- `ZCZC`: Start indicator
|
||
- `MessageID`: Unique message identifier (e.g., "TMQ1324")
|
||
- `DateTime`: Message date and time (e.g., "150631")
|
||
- `PriorityIndicator`: Message priority (e.g., "FF", "DD")
|
||
- `PrimaryAddress`: Primary recipient address (ICAO code)
|
||
- `SecondaryAddresses`: Additional recipient addresses
|
||
- `Originator`: Message originator (optional)
|
||
|
||
### Supported Message Types
|
||
|
||
The parser supports the following message categories:
|
||
|
||
#### 1. ARR - Arrival Message
|
||
|
||
Arrival messages report aircraft arrival information.
|
||
|
||
**Format:**
|
||
```
|
||
(ARR-<FlightNumber>[/<SSR>]-<DepartureAirport>-<ArrivalAirport><ArrivalTime>)
|
||
```
|
||
|
||
**Parsed Fields:**
|
||
- `category`: "ARR"
|
||
- `aircraft_id`: Aircraft identification/flight number
|
||
- `ssr_mode_and_code`: SSR mode and code (optional)
|
||
- `departure_airport`: Departure airport ICAO code
|
||
- `departure_time`: Departure time
|
||
- `arrival_airport`: Arrival airport ICAO code
|
||
- `arrival_time`: Arrival time
|
||
- `estimated_elapsed_time`: Estimated flight duration (optional)
|
||
- `alternate_airport`: Alternate airport (optional)
|
||
- `other_info`: Additional information (optional)
|
||
|
||
**Example:**
|
||
```
|
||
ZCZC ARR1234 150631
|
||
FF ZBTJZPZX
|
||
150630 ZBACZQZX
|
||
(ARR-CCA1234-A1234-ZBTJ1500-ZGGG0135)
|
||
NNNN
|
||
```
|
||
|
||
#### 2. DEP - Departure Message
|
||
|
||
Departure messages report aircraft departure information.
|
||
|
||
**Format:**
|
||
```
|
||
(DEP-<FlightNumber>[/<SSR>]-<DepartureAirport><DepartureTime>-<Destination>)
|
||
```
|
||
|
||
**Parsed Fields:**
|
||
- `category`: "DEP"
|
||
- `aircraft_id`: Aircraft identification/flight number
|
||
- `ssr_mode_and_code`: SSR mode and code (optional)
|
||
- `departure_airport`: Departure airport ICAO code
|
||
- `departure_time`: Departure time
|
||
- `destination`: Destination airport ICAO code
|
||
- `estimated_elapsed_time`: Estimated flight duration
|
||
- `alternate_airport`: Alternate airport (optional)
|
||
- `other_info`: Additional information (optional)
|
||
|
||
**Example:**
|
||
```
|
||
ZCZC DEP5678 120915
|
||
DD KLAXZPZX
|
||
120914 KSFOZQZX
|
||
(DEP-ABC5678-A1234-ZBTJ1440-ZGGG)
|
||
NNNN
|
||
```
|
||
|
||
#### 3. CNL - Cancellation Message
|
||
|
||
Cancellation messages indicate flight cancellations.
|
||
|
||
**Format:**
|
||
```
|
||
(CNL-<FlightNumber>-<DepartureAirport>-<DestinationAirport>)
|
||
```
|
||
|
||
**Parsed Fields:**
|
||
- `category`: "CNL"
|
||
- `aircraft_id`: Aircraft identification/flight number
|
||
- `departure_airport`: Departure airport ICAO code
|
||
- `destination_airport`: Destination airport ICAO code
|
||
- `other_info`: Additional information (optional)
|
||
|
||
**Example:**
|
||
```
|
||
ZCZC CNL9012 150631
|
||
FF ZBTJZPZX
|
||
(CNL-CCA9012-ZBTJ-ZGGG)
|
||
NNNN
|
||
```
|
||
|
||
#### 4. DLA - Delay Message
|
||
|
||
Delay messages report flight delays with new departure times.
|
||
|
||
**Format:**
|
||
```
|
||
(DLA-<FlightNumber>[/<SSR>]-<DepartureAirport>[<NewDepartureTime>]-<ArrivalAirport>[<ArrivalTime>])
|
||
```
|
||
|
||
**Parsed Fields:**
|
||
- `category`: "DLA"
|
||
- `aircraft_id`: Aircraft identification/flight number
|
||
- `ssr_mode_and_code`: SSR mode and code (optional)
|
||
- `departure_airport`: Departure airport ICAO code
|
||
- `new_departure_time`: New departure time (optional)
|
||
- `arrival_airport`: Arrival airport ICAO code
|
||
- `arrival_time`: Estimated arrival time (optional)
|
||
- `other_info`: Additional information (optional)
|
||
|
||
**Example:**
|
||
```
|
||
ZCZC DLA3456 150631
|
||
FF ZBTJZPZX
|
||
(DLA-CCA3456-A1234-ZBTJ1600-ZGGG0200)
|
||
NNNN
|
||
```
|
||
|
||
#### 5. FPL - Flight Plan Message
|
||
|
||
Flight plan messages contain detailed flight planning information.
|
||
|
||
**Format:**
|
||
```
|
||
(FPL-<FlightNumber>-<Indicator>
|
||
-<AircraftID>/<SSR>
|
||
-<DepartureAirport><DepartureTime>
|
||
-<Speed><Level> <Route>
|
||
-<Destination><EstimatedTime> <AlternateAirport>
|
||
-<OtherInfo>)
|
||
```
|
||
|
||
## Seed Tool: `cmd/seed-telegrams`
|
||
|
||
`seed-telegrams` 是一个开发/测试用的报文发生器，用来向 NATS/JetStream 持续或突发地发送合成电报（ARR/DEP/CNL/DLA/FPL），用于驱动解析与下游流水线。
|
||
|
||
### 支持的类别与内容
|
||
|
||
生成的电报遵循与解析器相同的格式约定：
|
||
|
||
- ARR / DEP：支持无 SSR、合法简单 SSR，以及刻意构造为“当前正则无法解析”的复杂 SSR。
|
||
- CNL / DLA：与 `internal/adapter/parser/aviation_parser_test.go` 中的测试样例同一类结构。
|
||
- FPL：生成包含多行 route 与 `OtherInfo` 字段的完整 FPL，`OtherInfo` 中会随机组合 `PBN/`, `NAV/`, `REG/`, `EET/`, `SEL/`, `PER/`, `RIF/`, `RMK/` 等片段，以覆盖解析逻辑。
|
||
|
||
### 命令行参数
|
||
|
||
常用参数：
|
||
|
||
- `--nats-url`：NATS 地址（默认 `nats://127.0.0.1:4222`，为空字符串则完全不连接 NATS）。
|
||
- `--subject`：普通 NATS 发布 subject（默认 `telegram.raw`）。
|
||
- `--jetstream`：是否使用 JetStream 发布。
|
||
- `--stream` / `--js-subject`：JetStream 相关选项。
|
||
- `--count`：要发送的电报数量（`mode=burst` 或有上限的 interval/mixed 时生效）。
|
||
- `--category`：`ARR|DEP|CNL|DLA|FPL|mixed`，`mixed` 表示在五类中随机选择。
|
||
- `--status`：`parsed|header_error|body_error|publish_error|repository_error|random`。
|
||
- `random` 模式下，合法报文偏向标记为 `parsed`，刻意非法报文偏向标记为 `body_error`。
|
||
- `--error-reason`：错误原因说明，将写入元数据 header（默认 `synthetic test payload`）。
|
||
- `--dry-run`：只打印电报内容，不真正发布到 NATS。
|
||
- `--header-format`：`json|none`，控制是否以 JSON 形式附加元数据 header。
|
||
- `--mode`：seed 模式：
|
||
- `burst`：一次性快速发送完 `count` 条。
|
||
- `interval`：按照给定时间间隔持续发送。
|
||
- `mixed`：先按 interval 发送一部分，再以 burst 方式发送剩余。
|
||
- `--interval-min` / `--interval-max`：`interval`/`mixed` 模式下两条电报之间的最小/最大间隔（默认 `1s` / `2s`）。
|
||
- `--duration`：`interval`/`mixed` 模式下的总持续时间，`0` 表示仅按 `count` 控制停止条件。
|
||
|
||
### 使用示例
|
||
|
||
#### 1. 一次性快速打 100 条（突发流量）
|
||
|
||
```bash
|
||
go run ./cmd/seed-telegrams \
|
||
--count=100 \
|
||
--mode=burst \
|
||
--category=mixed \
|
||
--status=random
|
||
```
|
||
|
||
#### 2. 模拟真实流量：每 1–2 秒发一条，持续 5 分钟
|
||
|
||
```bash
|
||
go run ./cmd/seed-telegrams \
|
||
--mode=interval \
|
||
--interval-min=1s \
|
||
--interval-max=2s \
|
||
--duration=5m \
|
||
--status=random \
|
||
--category=mixed
|
||
```
|
||
|
||
#### 3. 慢热 + 突发：前半段慢慢发，后半段瞬间打完
|
||
|
||
```bash
|
||
go run ./cmd/seed-telegrams \
|
||
--count=200 \
|
||
--mode=mixed \
|
||
--interval-min=500ms \
|
||
--interval-max=1500ms \
|
||
--status=random
|
||
```
|
||
|
||
#### 4. 只打印合成电报，不发送（本地调试报文格式）
|
||
|
||
```bash
|
||
go run ./cmd/seed-telegrams \
|
||
--count=5 \
|
||
--mode=burst \
|
||
--dry-run \
|
||
--category=FPL
|
||
```
|
||
|
||
#### 5. 持续缓慢发送（直到 Ctrl-C）
|
||
|
||
```bash
|
||
# 使用 Makefile/Taskfile 任务（推荐）
|
||
make seed-slow
|
||
# 或
|
||
task seed-slow
|
||
|
||
# 自定义间隔时间
|
||
make seed-slow INTERVAL_MIN=3s INTERVAL_MAX=8s
|
||
|
||
# 直接使用命令行
|
||
go run ./cmd/seed-telegrams \
|
||
--nats-url nats://localhost:4222 \
|
||
--jetstream \
|
||
--stream TELEGRAM \
|
||
--js-subject telegram.serial \
|
||
--mode interval \
|
||
--interval-min 2s \
|
||
--interval-max 5s \
|
||
--count 0
|
||
```
|
||
|
||
**注意**：设置 `--count 0` 会持续发送直到手动停止（Ctrl-C）。这对于长时间测试和监控系统行为非常有用。
|
||
|
||
该工具专门为开发与测试设计，不影响生产服务逻辑，推荐在本地或测试环境配合解析与存储流水线一起使用，用于回归测试、吞吐量观察和错误场景演练。
|
||
|
||
**Parsed Fields:**
|
||
- `category`: "FPL"
|
||
- `flight_number`: Flight number
|
||
- `reference_data`: Reference data (optional)
|
||
- `aircraft_id`: Aircraft identification
|
||
- `ssr_mode_and_code`: SSR mode and code
|
||
- `flight_rules_and_type`: Flight rules and type
|
||
- `cruising_speed_and_level`: Cruising speed and flight level
|
||
- `departure_airport`: Departure airport ICAO code
|
||
- `departure_time`: Departure time
|
||
- `route`: Flight route
|
||
- `destination_and_total_time`: Destination and estimated total time
|
||
- `alternate_airport`: Alternate airport (optional)
|
||
- `estimated_arrival_time`: Estimated arrival time
|
||
- `pbn`: Performance-based navigation equipment
|
||
- `navigation_equipment`: Navigation equipment
|
||
- `estimated_elapsed_time`: Estimated elapsed time
|
||
- `selcal_code`: SELCAL code
|
||
- `register`: Aircraft registration (optional)
|
||
- `performance_category`: Performance category
|
||
- `reroute_information`: Reroute information (optional)
|
||
- `remarks`: Remarks (optional)
|
||
|
||
**Example:**
|
||
```
|
||
ZCZC FPL7890 150631
|
||
FF ZBTJZPZX
|
||
(FPL-JAE7433-IS
|
||
-B744/H-SXIRPZJWY/S
|
||
-ZBTJ1755
|
||
-K0926S0920 CG A326 VYK W80 HUR B339 GM A575 MANSA/K0919S0980
|
||
-EDDF0948 EDDK
|
||
-EET/ZMUB0100 UNKL0236
|
||
REG/B2422 SEL/JLAD
|
||
NAV/RNAV1 RNAV5 RNP4
|
||
RMK/AGCS EQUIPPED)
|
||
NNNN
|
||
```
|
||
|
||
### Parsing Process
|
||
|
||
1. **Header Parsing**: The parser extracts header information including message ID, date/time, priority, and addresses
|
||
2. **Category Detection**: The parser identifies the message category from the body content
|
||
3. **Body Parsing**: Based on the category, the parser applies the appropriate regex pattern to extract structured data
|
||
4. **Data Mapping**: Extracted data is mapped to domain model structures (ARR, DEP, CNL, DLA, or FPL)
|
||
5. **Storage**: The parsed message is stored in PostgreSQL with:
|
||
- Raw content in `content` field
|
||
- Parsed structured data in `body_data` field (JSONB)
|
||
- Metadata in dedicated columns
|
||
|
||
### Parsed Message Structure
|
||
|
||
All parsed messages are stored in the `ParsedMessage` domain model:
|
||
|
||
```go
|
||
type ParsedMessage struct {
|
||
Uuid string // Unique identifier
|
||
MessageID string // Telegram message ID
|
||
DateTime string // Message date/time
|
||
PriorityIndicator string // Priority level
|
||
PrimaryAddress string // Primary recipient
|
||
SecondaryAddresses string // Secondary recipients
|
||
Originator string // Message originator
|
||
OriginatorDateTime string // Originator date/time
|
||
Category string // Message category (ARR, DEP, CNL, DLA, FPL)
|
||
Content string // Raw message content
|
||
BodyData interface{} // Parsed body data (ARR, DEP, CNL, DLA, or FPL struct)
|
||
ReceivedAt time.Time // Reception timestamp
|
||
ParsedAt time.Time // Parsing timestamp
|
||
DispatchedAt time.Time // Dispatch timestamp
|
||
NeedDispatch bool // Dispatch flag
|
||
Parsed bool // Parsing success flag
|
||
Comments string // Parsing comments/errors
|
||
}
|
||
```
|
||
|
||
### Error Handling
|
||
|
||
- **Invalid Format**: Messages that don't match expected formats are stored with `Parsed = false` and error details in `Comments`
|
||
- **Partial Parsing**: Header parsing failures result in storing raw content only
|
||
- **Category Mismatch**: Unsupported categories are logged and stored with parsing errors
|
||
|
||
## Database Schema
|
||
|
||
The application uses the `aviation.telegrams` table. See `internal/infra/postgres/telegrams.ddl` for the schema definition.
|
||
|
||
Key fields:
|
||
- `uuid`: Primary key (UUID)
|
||
- `message_id`: Telegram message ID
|
||
- `content`: Raw message content
|
||
- `body_data`: Parsed body data (JSONB)
|
||
- `received_at`, `parsed_at`, `dispatched_at`: Timestamps
|
||
|
||
## Logging
|
||
|
||
Logging uses Zap with structured logging. Log levels and format can be configured:
|
||
|
||
- **Levels**: `debug`, `info`, `warn`, `error`
|
||
- **Formats**: `json` (production) or `console` (development)
|
||
|
||
Logs include contextual information:
|
||
- Message IDs
|
||
- Subject names
|
||
- Stream names
|
||
- Processing attempts
|
||
|
||
## Performance
|
||
|
||
- **Batch Processing**: Messages are processed in configurable batches (default: 50)
|
||
- **Database Inserts**: Uses PostgreSQL `COPY FROM` for efficient batch inserts
|
||
via `Repository.InsertBatch`. The default processor issues single inserts,
|
||
but you can switch to buffered batches in high-throughput deployments.
|
||
- **Connection Pooling**: Configurable PostgreSQL connection pool
|
||
- **JetStream**: Reliable message delivery with automatic retries
|
||
|
||
## Troubleshooting
|
||
|
||
### Connection Issues
|
||
|
||
- **NATS**: Check that NATS server is running and JetStream is enabled
|
||
- **PostgreSQL**: Verify database connection string and that the schema exists
|
||
|
||
### Message Processing Issues
|
||
|
||
- Check logs for parsing errors
|
||
- Verify message format matches expected telegram format
|
||
- Check database constraints and indexes
|
||
|
||
### Configuration Issues
|
||
|
||
- Ensure `GO_ENV` is set correctly
|
||
- Verify configuration file exists at `configs/config.{env}.toml`
|
||
- Check environment variable names use `CAATSM_` prefix
|
||
|
||
## Migration from Legacy System
|
||
|
||
This project was refactored from:
|
||
- **Watermill** → **nats.go JetStream**
|
||
- **Hasura GraphQL** → **PostgreSQL pgx**
|
||
- **Viper** → **Koanf**
|
||
- **Manual DI** → **Google Wire**
|
||
|
||
The legacy code has been removed. See the project history for migration details.
|
||
|
||
## License
|
||
|
||
This repository has not declared a public license yet.
|
||
|
||
## Contributing
|
||
|
||
Contribution guidelines are not published; please coordinate changes via pull requests or direct maintainers.
|