The CSS ::before/::after pseudo-elements for [ ] brackets were rendering
on separate lines because button HTML had multiline whitespace (newlines +
indentation) inside the tag, causing:
[
Button Text
]
Fix: set button display to inline-flex with align-items:center so
pseudo-elements become flex children that stay on the same line
as button content regardless of internal whitespace. Also add
white-space:nowrap and flex-shrink:0 on pseudo-elements.
Also fix compareBtn.style.display to use inline-flex to avoid
reverting to block-level display that would re-introduce wrapping.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Remove manual [ ] from sub-tab buttons (Manual Runs, Automated)
- Add CSS to suppress button::before/after pseudo-elements on .tab
buttons and border:none inline-styled buttons so they don't get
double-bracketed
- Prevents [[ text ]] from appearing on Templates/History/sub-tabs
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Root cause: CSS button::before/after adds [ ] universally, but many
buttons had hardcoded [ text ] content, producing [[ text ]].
- Strip manual [ ] wrappers from all button text in HTML and JS
- Fix JS textContent assignments for compare mode buttons
- Fix dynamic button HTML strings in execution details panel
- Add formatLogEntry handlers for previously unhandled action types:
dry_run_skipped, execution_timeout, goto_error, step_error,
workflow_result, params, server_restart_recovery
- Unknown log actions now show action name instead of raw JSON
- Add cron schedule type display in schedules list
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Rate limiting: 300 req/15min general, 20 req/min on POST /api/executions
- Cron schedule type support using cron-parser for full cron expressions
- Webhook notifications: POST to workflow webhook_url on execution complete/failed
- Dry-run mode: simulate workflow execution without running any commands
- Global execution timeout via EXECUTION_MAX_MINUTES env var (default 60min)
- Execution filtering: status, workflow_id, started_by, after, before, search
- Event-driven command result delivery (replaces 500ms DB polling)
- Atomic log appends via JSON_ARRAY_APPEND (no read-modify-write race)
- Separate browserClients/workerClients sets (workers no longer receive broadcasts)
- Stale execution cleanup on startup (mark running→failed after crash)
- Scheduler overlap prevention (skip if same workflow already running)
- Frontend: webhook_url field in create/edit workflow modals
- Frontend: dry-run checkbox in workflow param modal
- Frontend: ESC closes modals, ws.onerror handler added
- Frontend: selectedExecutions changed from Array to Set (O(1) ops)
- Frontend: XSS fixes via escapeHtml() on all user-controlled innerHTML
- Frontend: param modal keydown listener deduplication fix
- Remove unused npm packages (bcryptjs, body-parser, cors, js-yaml, jsonwebtoken)
- Add express-rate-limit and cron-parser dependencies
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Automated executions (started_by gandalf: or scheduler:) no longer
trigger success/failure toast alerts for connected browser users.
Server now includes is_automated flag in command_result broadcasts.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Worker does not echo command_id back in command_result message.
Previously this caused all workflow steps to time out after 120s.
Now: find the command_sent entry for the commandId, then take the
next command_result after it — safe since steps run sequentially.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- server.js: add authenticateGandalf middleware (X-Gandalf-API-Key header)
and two internal endpoints used by Gandalf link diagnostics:
POST /api/internal/command — submit SSH command to a worker, returns execution_id
GET /api/internal/executions/:id — poll execution status/logs
Also tag automated executions as started_by 'gandalf:*' / 'scheduler:*';
add hide_internal query param to GET /api/executions; change cleanup
from daily/30d to hourly/1d to keep execution history lean
- index.html: add Manual / Automated sub-tabs on Execution History tab so
Gandalf diagnostic runs don't clutter the manual run view; persists
selected tab to localStorage; dashboard recent-run strip filters to
manual runs only; sub-tabs show live counts
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Wrapped ws.onmessage in try-catch to capture full stack trace
when errors occur during message handling. This will help identify
where the 'Cannot read properties of undefined' error is coming from.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This will help diagnose the 'Cannot read properties of undefined' error
by logging each step of the workflow creation process.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Separated JSON validation from API call error handling
- Changed refreshData() to async with individual try-catch blocks
- Better error messages: "Invalid JSON" vs "Error creating workflow"
- Console.error logging for each data loading function
- Changed success alert to terminal notification
- This will help identify which specific function is failing
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Removed old/obsolete workflow execution system that was conflicting
with the new executeWorkflowSteps() engine:
Removed:
- activeExecutions Map (old tracking system)
- executeWorkflow() - old workflow executor
- executeNextStep() - old step processor
- executeCommandStep() - old command executor (duplicate)
- handleUserInput() - unimplemented prompt handler
- Duplicate app.post('/api/executions') endpoint
- app.post('/api/executions/:id/respond') endpoint
This was causing "Cannot read properties of undefined (reading 'target')"
error because the old code was being called instead of the new engine.
The new executeWorkflowSteps() engine is now the only workflow system.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Added comprehensive command scheduling system:
Backend:
- New scheduled_commands database table
- Scheduler processor runs every minute
- Support for three schedule types: interval, hourly, daily
- calculateNextRun() function for intelligent scheduling
- API endpoints: GET, POST, PUT (toggle), DELETE
- Executions automatically created and tracked
- Enable/disable schedules without deleting
Frontend:
- New Scheduler tab in navigation
- Create Schedule modal with worker selection
- Dynamic schedule input based on type
- Schedule list showing status, next/last run times
- Enable/Disable toggle for each schedule
- Delete schedule functionality
- Terminal-themed scheduler UI
- Integration with existing worker and execution systems
Schedule Types:
- Interval: Every X minutes (e.g., 30 for every 30 min)
- Hourly: Every X hours (e.g., 2 for every 2 hours)
- Daily: At specific time (e.g., 03:00 for 3 AM daily)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Added powerful execution comparison and diff view:
- Compare Mode toggle button in executions tab
- Multi-select up to 5 executions for comparison
- Visual selection indicators with checkmarks
- Comparison modal with summary table (status, duration, timestamps)
- Side-by-side output view for all selected executions
- Line-by-line diff analysis for 2-execution comparisons
- Highlights identical vs. different lines
- Shows identical/different line counts
- Color-coded diff (green for exec 1, amber for exec 2)
- Perfect for comparing same command across workers
- Terminal-themed comparison UI
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Added comprehensive search and filtering for execution history:
- Search bar to filter by command text, execution ID, or workflow name
- Status filter dropdown (All, Running, Completed, Failed, Waiting)
- Real-time client-side filtering as user types
- Filter statistics showing X of Y executions
- Clear Filters button to reset all filters
- Extracts command text from logs for quick command searches
- Maintains all executions in memory for instant filtering
- Terminal-themed filter UI matching existing aesthetic
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Added ability to execute commands on multiple workers simultaneously:
- Added execution mode selector (Single/Multiple Workers)
- Multi-worker mode with checkbox list for worker selection
- Helper buttons: Select All, Online Only, Clear All
- Sequential execution across selected workers
- Results summary showing success/fail count per worker
- Updated command history to track multi-worker executions
- Terminal beep feedback based on overall success/failure
- Maintained backward compatibility with single worker mode
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
- Handle new pagination response format (data.executions vs data)
- Request up to 1000 executions to ensure all are checked
- Track successful deletions count
- Use terminal notification instead of alert
- Better error handling for individual delete failures
Fixes regression from Phase 5 pagination changes.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
- Added blinking terminal cursor animation
- Smooth hover effects for execution/worker/workflow items
- Hover animation: background highlight + border expand + slide
- Loading pulse animation for loading states
- Slide-in animation for log entries
- Terminal beep sound using Web Audio API (different tones for success/error)
- Real-time terminal notifications for command completion
- Toast-style notifications with green glow effects
- Auto-dismiss after 3 seconds with fade-out
- Visual and audio feedback for user actions
Sound features:
- 800Hz tone for success (higher pitch)
- 200Hz tone for errors (lower pitch)
- 440Hz tone for info (standard A note)
- 100ms duration, exponential fade-out
- Graceful fallback if Web Audio API not supported
Notification features:
- Fixed position top-right
- Terminal-themed styling with glow
- Color-coded: green for success, red for errors
- Icons: ✓ success, ✗ error, ℹ info
- Smooth animations (slide-in, fade-out)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
Server-side:
- Added automatic cleanup of old executions (runs daily)
- Configurable retention period via EXECUTION_RETENTION_DAYS env var (default: 30 days)
- Cleanup runs on server startup and every 24 hours
- Only cleans completed/failed executions, keeps running ones
- Added pagination support to /api/executions endpoint
- Returns total count, limit, offset, and hasMore flag
Client-side:
- Implemented "Load More" button for execution pagination
- Loads 50 executions at a time
- Appends additional executions when "Load More" clicked
- Shows total execution count info
- Backward compatible with old API format
Benefits:
- Automatic database maintenance
- Prevents execution table from growing indefinitely
- Better performance with large execution histories
- User can browse all executions via pagination
- Configurable retention policy per deployment
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
- Added "Re-run Command" button to execution details modal
- Added "Download Logs" button to export execution data as JSON
- Re-run automatically switches to Quick Command tab and pre-fills form
- Download includes all execution metadata and logs
- Buttons only show for applicable execution types
- Terminal-themed button styling
Features:
- Re-run: Quickly repeat a previous command on same worker
- Download: Export execution logs for auditing/debugging
- JSON format includes: execution_id, status, timestamps, logs
- Filename includes execution ID and date for easy organization
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
- Added command templates modal with 12 common system commands
- Added command history tracking (stored in localStorage)
- History saves last 50 commands with timestamp and worker name
- Template categories: system info, disk/memory, network, Docker, logs
- Click templates to auto-fill command field
- Click history items to reuse previous commands
- Terminal-themed modals with green/amber styling
- History persists across browser sessions
Templates included:
- System: uname, uptime, CPU info, processes
- Resources: df -h, free -h, memory usage
- Network: ip addr, active connections
- Docker: container list
- Logs: syslog tail, who is logged in, last logins
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
- Show worker system metrics in dashboard and worker list
- Display CPU cores, memory usage, load average, uptime
- Added formatBytes() to display memory in human-readable format
- Added formatUptime() to show uptime as days/hours/minutes
- Added getTimeAgo() to show relative last-seen time
- Improved worker list with detailed metadata panel
- Show active tasks vs max concurrent tasks
- Terminal-themed styling for metadata display
- Amber labels for metadata fields
Benefits:
- See worker health at a glance
- Monitor resource usage (CPU, RAM, load)
- Track worker activity (active tasks)
- Better operational visibility
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
- Added formatLogEntry() function to parse and format log entries
- Replaced raw JSON display with readable formatted logs
- Added specific formatting for command_sent and command_result logs
- Show timestamp, status, duration, stdout/stderr in organized layout
- Color-coded success (green) and failure (red) states
- Added scrollable output sections with max-height
- Syntax highlighting for command code blocks
- Terminal-themed styling with green/amber colors
Benefits:
- Much easier to read execution logs
- Clear visual distinction between sent/result logs
- Professional terminal aesthetic maintained
- Better UX for debugging command execution
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Problem:
- Workers generate random UUID on startup (runtime ID)
- Database stores workers with persistent IDs (database ID)
- UI sends commands using database ID
- Server couldn't find worker connection (stored by runtime ID)
- Result: 400 Bad Request "Worker not connected"
Solution:
- When worker connects, look up database ID by worker name
- Store WebSocket connection in Map using BOTH IDs:
* Runtime ID (from worker_connect message)
* Database ID (from database lookup by name)
- Commands from UI use database ID → finds correct WebSocket
- Cleanup both IDs when worker disconnects
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
- Removed duplicate /api/executions/:id endpoint that didn't parse logs
- Added workers Map to track worker_id -> WebSocket connection
- Store worker connections when they send worker_connect message
- Send commands to specific worker instead of broadcasting to all clients
- Clean up workers Map when worker disconnects
- Update execution status to completed/failed when command results arrive
- Add proper error handling when worker is not connected
Fixes:
- execution.logs.forEach is not a function (logs now properly parsed)
- Commands stuck in "running" status (now update to completed/failed)
- Commands not reaching workers (now sent to specific worker WebSocket)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
- Removed all migration code from server.js
- Database schema fixed directly via MySQL:
* Dropped users.role column (SSO only)
* Dropped users.password column (SSO only)
* Added executions.started_by column
* Added workflows.created_by column
* All tables now match expected schema
- Server startup will be faster without migrations
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
- Drop password column from users table (SSO authentication only)
- PULSE uses Authelia SSO, not password-based authentication
- Fixes 500 error: Field 'password' doesn't have a default value
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
- Add display_name, email, and groups columns to existing users table
- Handle MariaDB lack of IF NOT EXISTS in ALTER TABLE
- Gracefully skip columns that already exist
- Fixes 500 error when authenticating users
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
- Modified executions table schema to allow NULL workflow_id
- Removed foreign key constraint that prevented NULL values
- Added migration to update existing table structure
- Quick commands can now be stored without a workflow reference
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes:
- Create execution record in database when quick command is sent
- Store initial log entry with command details
- Broadcast execution_started event to update UI
- Display quick commands as "[Quick Command]" in execution list
- Fix worker communication to properly track all executions
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
