x/platform
1
0
Fork 0
Code Issues Pull requests Projects Releases 12 Packages Wiki Activity Actions
12 releases 12 tags
  • v0.6.5 0b67d2ead8

    v0.6.5 Stable

    x released this 2026-02-26 13:45:57 +00:00 | 2 commits to main since this release

    Signed by x
    GPG key ID: A14ACA8AB45A9C27

    VSKI v0.6.5

    Features

    Workflow Execution on Replicas

    Replicas can now execute workflows locally using their own workflows.db database. Since workflows.db and stats.db are excluded from replication, each replica maintains independent workflow state while still having access to synced user data from default.db.

    This enables:

    • Distributed workflow processing - Workers can run on any replica
    • Load distribution - Offload workflow execution from master
    • Local stats collection - Each replica tracks its own statistics

    Configuration

    No additional configuration required. Workflows automatically work on replicas when:

    • Replica has its own workflows.db (created automatically)
    • Workflow endpoints are excluded from read-only middleware
    # Replica configuration
REPLICA_MODE=replica
MASTER_URL=https://master.example.com
SYNC_INTERVAL=60

# Workflows run locally on replica
# Workers connect to replica's /api/workflow/ws endpoint

    File Replication for Replicas

    When using local storage (not S3), replicas can now automatically sync uploaded files from the master server. This ensures file attachments are available on replica servers alongside the database data.

    How It Works

    1. File Journal: Master server tracks file operations (add/delete) in a _file_journal table
    2. Automatic Sync: After each database sync, replicas fetch and apply file changes
    3. Dual Cleanup Strategy:
      • Ack-based: Journal entries are removed after replicas confirm sync
      • Time-based: Entries older than the retention period are automatically cleaned up

    Configuration

    # Master server - file journal is created automatically when:
# - Not in replica mode
# - Not using S3 storage
FILE_SYNC_RETENTION_DAYS=7  # Default: 7 days

# Replica server - file sync is enabled automatically when:
# - REPLICA_MODE=replica
# - Not using S3 storage
REPLICA_MODE=replica
MASTER_URL=https://master.example.com
SYNC_INTERVAL=60

    New Replica Endpoints

    Endpoint Description
    GET /api/replica/files?since=<id> List file journal entries since the given ID
    GET /api/replica/file/*path Download a file from the master server
    POST /api/replica/files/ack Acknowledge synced files (triggers cleanup)

    Technical Details

    • File journal is stored in default.db and replicates with the database
    • Sync happens immediately after each database sync cycle
    • Files are verified with SHA256 checksum during transfer
    • Journal cleanup runs every 24 hours on the master

    New Environment Variables

    Variable Default Description
    FILE_SYNC_RETENTION_DAYS 7 Days to retain file journal entries (time-based cleanup)

    Technical Details

    Files Changed

    • internal/config/config.go - Added FileSyncRetentionDays config option
    • internal/db/db.go - Added _file_journal table and index
    • internal/replica/file_journal.go - New file journal service with cleanup scheduler
    • internal/replica/syncer.go - Added file sync methods
    • internal/replica/types.go - Added file sync request/response types
    • internal/api/replica.go - Added file sync endpoints
    • internal/services/storage.go - Added journal recording for file operations
    • internal/api/records.go - Record deletion now triggers file cleanup
    • internal/app/bootstrap.go - Wired up file journal and cleanup scheduler

    Breaking Changes

    None. File replication is automatic when using local storage in replica mode. S3 storage continues to handle file replication independently.

    Migration

    No migration required. The _file_journal table is created automatically on startup for master servers using local storage.

    Downloads