Rewrite docs/api.md to provide a more structured overview of business
logic, core models, and authentication mechanisms. Include detailed
cURL examples for typical operations and add a new management
relationship diagram asset.
- Significant rewrite of docs/api.md with better formatting and content
- Add mermaid diagram for resource relationships
- Update README.md to reference the expanded documentation
- Add docs/管理关系图.png asset
Add separate log-postgres service to docker-compose stack for storing
API logs independently from the main database.
- Add log-postgres service with PostgreSQL 15 Alpine image
- Configure environment variables for log database credentials
- Update ez-api service to depend on log-postgres health check
- Set default EZ_LOG_PG_DSN to connect to the new log database
- Update .env.example and README with new configuration options
Introduce StatsService integration to admin and master handlers,
exposing realtime metrics (requests, tokens, QPS, rate limit status)
via new endpoints:
- GET /admin/masters/:id/realtime
- GET /v1/realtime
Also embed realtime stats in the existing GET /admin/masters/:id
response and change GlobalQPS default to 0 with validation to
reject negative values.
Implement webhook notifications for log error threshold alerts with
configurable thresholds, time windows, and cooldown periods.
- Add LogWebhookService with Redis-backed configuration storage
- Add admin endpoints for webhook config management (GET/PUT)
- Trigger webhook notifications when error count exceeds threshold
- Support status code threshold and error message detection
- Include sample log record data in webhook payload
Add runtime feature flag to control whether request bodies are stored
in logs. The Handler now accepts a Redis client to check the
log_request_body_enabled feature flag before persisting log records.
- Add logRequestBodyFeatureKey constant for feature flag
- Inject Redis client into Handler for feature flag lookups
- Strip request body from log records when feature is disabled
- Update tests to pass Redis client to NewHandler
Add tests for UpdateFeatures endpoint covering:
- Regular feature flag keys with various value types
- Mixed keys combining feature flags with log retention settings
- Redis storage verification for both scenarios
Add special handling for log_retention_days and log_max_records features
that are stored as separate Redis keys instead of in the features hash.
- Store log overrides in dedicated keys (meta:log:retention_days,
meta:log:max_records) for runtime access by log cleanup cron
- Include log override values in ListFeatures response
- Support clearing overrides by setting value to 0
- Add comprehensive tests for log override CRUD operations
Implement LogCleaner cron job to automatically clean up old log records
based on configurable retention period and maximum record count.
- Add LogCleaner with retention_days and max_records configuration
- Add EZ_LOG_RETENTION_DAYS and EZ_LOG_MAX_RECORDS environment variables
- Default to 30 days retention and 1,000,000 max records
- Include unit tests for log cleaner functionality
- Add `POST /admin/providers/preset` for streamlined creation of official providers (OpenAI, Anthropic, Gemini)
- Add `POST /admin/providers/custom` for generic OpenAI-compatible providers
- Add `weight` field to provider model and DTOs to enable weighted routing
- Update sync service to propagate provider weights
- Add unit tests for new creation handlers
Add unit tests for the SyncBindings service covering exact matching,
regex selectors, and normalized matching logic using in-memory
dependencies (SQLite and MiniRedis) to ensure correct upstream
resolution.
Add endpoints for master and key access management to configure default
and allowed namespaces, including propagation options.
Implement GET and DELETE operations for individual bindings.
Update sync service to persist bindings snapshots even when no upstreams
are available.
Standardize alignment of struct tags in models and field assignments in
services for better readability. Additionally, include the Binding model
in the test database auto-migration.
Implement handlers for creating, listing, and updating model bindings.
Register new routes in the admin server group and add DTO definitions.
Update provider handlers to trigger binding synchronization on changes
to ensure upstream mappings remain current.
Introduce namespace-aware routing capabilities through a new Binding
model and updates to Master/Key entities.
- Add Binding model for configuring model routes per namespace
- Add DefaultNamespace and Namespaces fields to Master and Key models
- Update auto-migration to include Binding table
- Implement Redis synchronization for binding configurations
- Propagate namespace settings during master creation and key issuance
Reflect recent API changes in Swagger documentation:
- Add endpoints for feature flag management (/admin/features)
- Add endpoint for issuing child keys to masters (/admin/masters/{id}/keys)
- Add endpoint for updating providers (/admin/providers/{id})
- Update provider model definitions with new fields (auto_ban, google_* attributes, status)
Add `POST /admin/masters/{id}/keys` allowing admins to issue child keys
on behalf of a master. Introduce an `issued_by` field in the Key model
to audit whether a key was issued by the master or an admin.
Refactor master service to use typed errors for consistent HTTP status
mapping and ensure validation logic (active status, group check) is
shared.
Add FeatureHandler to manage lightweight runtime configuration toggles
stored in the Redis `meta:features` hash. This enables dynamic control
over system behavior (e.g., storage backends) via the admin API.
- Add `GET /admin/features` to list flags
- Add `PUT /admin/features` to update flags
- Update README with feature flag documentation
- Update TESTING.md to reflect current testing status and future plans
- Add golden file comparison for provider snapshot validation in sync_test.go
- Introduce master_test.go for testing Master/Key functionality
- Add testdata directory for contract testing snapshots
Introduce a middleware layer to attach a unique identifier to each HTTP request for observability purposes. The identifier is propagated via the X-Request-ID header, allowing for correlation of logs and events across distributed system components.
Add request ID middleware to trace requests through the system. The middleware checks for existing X-Request-ID headers, generates a new UUID if not present, and sets the ID in both request/response headers and Gin context.
