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.