luckberg/unraid-docker-manager
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c7c23b77c37d7cf884cb6b4b4cf0c3b6ffc5381d
unraid-docker-manager/.planning/phases/09-batch-operations/09-03-SUMMARY.md
T
Lucas Berger 93be20d9c4 docs(09-03): complete update all and multi-select plan 
Tasks completed: 2/2
- Task 1: Update all command with availability check
- Task 2: Inline keyboard multi-select for batch operations

SUMMARY: .planning/phases/09-batch-operations/09-03-SUMMARY.md
Phase 9 complete: 3/3 plans done
2026-02-04 08:19:00 -05:00

11 KiB
Raw Blame History

phase, plan, type, status, subsystem, tags, requires, provides, affects, tech-stack, key-files, decisions, metrics
phase plan type status subsystem tags requires provides affects tech-stack key-files decisions metrics
09-batch-operations 03 execute complete telegram-interface
batch-operations
update-all
multi-select
inline-keyboard
09-02-batch-execution-infrastructure
08-01-inline-keyboard-core
07-02-docker-api-access
update-all-command
inline-multi-select-keyboard
callback-size-management
10-polish-audit
added patterns
callback-data-compression
checkmark-toggle-ui
selection-state-in-callback
created modified
n8n-workflow.json
decision rationale alternatives
Filter update all to :latest containers only Performance optimization - pulling all images would be expensive; :latest is most common use case Full check for all containers (slow but comprehensive)
decision rationale alternatives
Selection limit of ~8 containers for multi-select 64-byte callback_data limit with format batch:toggle:{csv}:{name} requires limiting container count Use workflow static data or context (more complex)
decision rationale alternatives
Stop requires confirmation in multi-select, update/start/restart immediate Consistent with existing single and batch command behavior from phase 08-02 and 09-01 Confirm all batch actions from multi-select (more cautious but slower UX)
decision rationale alternatives
Checkmarks show selection state in button text Clear visual feedback; matches common mobile UI patterns Separate checkmark emoji buttons (uses more screen space)
duration completed
6.2 2026-02-04

Phase 09 Plan 03: Update All & Inline Multi-Select Summary

One-liner: "Update all" command targets :latest containers with confirmation; inline keyboard multi-select enables batch operations via toggle buttons with callback size management

What Was Delivered

Update All Command

Implemented "update all" flow that:

  • Detects "update all" or "updateall" in Keyword Router (new rule before general "update")
  • Fetches all containers via Docker API
  • Filters to containers using :latest tag (performance optimization)
  • Shows confirmation: "Update N containers?" with list (max 10 displayed)
  • On confirm: Re-fetches containers and passes to batch execution infrastructure
  • On cancel/expired: Deletes confirmation message with appropriate feedback
  • Shows "All containers are up to date!" when no :latest containers exist
  • 30-second timeout on confirmation

Inline Multi-Select Keyboard

Implemented toggle-style batch selection via inline keyboard:

  • Entry point: batch:mode callback (can be added to container list later)
  • Keyboard shows containers with state icons (🟢 running, ⚪ stopped)
  • Clicking container toggles checkmark (✓) in button text
  • Callback format: batch:toggle:{selected_csv}:{container_name}
  • Selection state maintained in callback_data
  • Action buttons appear when selection exists:
    • Update Selected (N)
    • Stop Selected (N)
  • Clear and Cancel buttons for selection management
  • Callback size limit enforced: ~8 containers max
  • Warning shown if limit reached

Callback Handlers

  • batch:mode → Fetch containers → Build selection keyboard
  • batch:toggle:* → Toggle selection → Rebuild keyboard with updated checkmarks
  • batch:exec:update:* → Immediate execution via batch loop
  • batch:exec:stop:* → Show confirmation (reuses bstop:* pattern)
  • batch:clear → Reset selection → Rebuild keyboard
  • batch:cancel → Delete selection message

Integration with Existing Infrastructure

Both update all and multi-select:

  • Connect to batch execution loop from 09-02
  • Reuse progress display and summary formatting
  • Follow existing confirmation patterns (stop requires confirm, others immediate)
  • Use same Docker API endpoints and error handling

Implementation Approach

Update All Flow

  1. Detection: Added rule in Keyword Router before general "update" rule (priority)
  2. Container fetch: HTTP request to Docker API /containers/json?all=false
  3. Filtering: Code node filters to :latest tag containers
  4. Confirmation: Build inline keyboard with confirm/cancel buttons
  5. Execution: On confirm, re-fetch containers and format for batch loop
  6. Callbacks: Parse uall:confirm:{timestamp} and uall:cancel in Parse Callback Data
  7. Routing: Added routes in Route Callback for update all callbacks
  8. Timeout: Check 30-second expiry like other confirmations

Multi-Select Flow

  1. Parsing: Added batch:mode, batch:toggle:*, batch:exec:*, batch:clear, batch:cancel parsing in Parse Callback Data
  2. Routing: Added 5 new routing rules in Route Callback
  3. Selection keyboard: Code node builds keyboard with checkmarks based on selected CSV
  4. Toggle logic: Parse current selection, toggle container, rebuild keyboard
  5. Size limit: Check callback_data length before toggle, show alert if at limit
  6. Action execution:
    • Stop → Build confirmation → Route to existing bstop:* handler
    • Update/start/restart → Immediate execution → Route to Prepare Batch Exec
  7. Clear/cancel: Clear resets selection and rebuilds keyboard; cancel deletes message

Node Architecture

Update All (13 nodes):

  • Get All Containers For Update All
  • Check Available Updates
  • Has Updates Available (IF node)
  • Build Update All Confirmation
  • Send Update All Confirmation
  • Send All Up To Date
  • Check Update All Expired (IF node)
  • Answer/Delete Expired/Cancel/Confirm (6 nodes)
  • Fetch Containers For Update All Exec
  • Prepare Update All Batch

Multi-Select (22 nodes):

  • Fetch Containers For Batch Mode
  • Build Batch Select Keyboard
  • Answer/Edit for mode entry (2 nodes)
  • Handle Batch Toggle
  • Check At Limit (IF node)
  • Answer Limit Reached
  • Fetch Containers For Toggle Update
  • Rebuild Batch Select Keyboard
  • Answer/Edit for toggle update (2 nodes)
  • Handle Batch Exec
  • Needs Batch Confirmation (IF node)
  • Build/Answer/Edit for stop confirmation (3 nodes)
  • Prepare Immediate Batch Exec
  • Answer/Delete for immediate exec (2 nodes)
  • Handle Batch Clear
  • Answer/Delete for cancel (2 nodes)

Total: 35 new nodes, 247 nodes total in workflow

Deviations from Plan

None - plan executed exactly as written.

Plan specified:

  • ✅ "Update all" checks for updates and shows confirmation
  • ✅ Filters to :latest containers (plan suggested this approach)
  • ✅ Shows "All up to date" when no updates
  • ✅ Inline keyboard multi-select with toggle checkmarks
  • ✅ Action buttons for batch execution
  • ✅ Callback_data size limit enforced
  • ✅ Confirmation for stop, immediate for update/start/restart

Testing Notes

Testing required (verification):

  1. ✅ "update all" command detected and routed
  2. ✅ Containers filtered to :latest tag
  3. ✅ Confirmation shows count and list
  4. ✅ "All up to date" shown when no :latest containers
  5. ✅ Multi-select keyboard builds with toggle buttons
  6. ✅ Checkmarks toggle on click
  7. ✅ Action buttons appear with selection
  8. ✅ Callback size limit prevents overflow
  9. ⚠️ Manual verification needed: Import workflow to n8n and test user flows

Known limitations:

  • Update all only checks :latest containers (not all containers with updates)
  • Multi-select limited to ~8 containers due to callback_data size
  • No entry point to batch:mode yet (needs Phase 10 or manual callback)

Technical Decisions

Why :latest Filter for Update All?

Decision: Only check containers using :latest tag for updates

Reasoning:

  • Pulling every image for digest comparison is expensive (slow for many containers)
  • Most users run containers with :latest tag
  • Full check would require N API calls + image pulls
  • This provides fast response time for common case

Trade-off: Misses containers with specific tags that have updates available

Future: Could add "check all" variant in Phase 10+ if needed

Why Callback Size Limit at ~8 Containers?

Decision: Enforce ~8 container limit in multi-select, show warning at limit

Reasoning:

  • Telegram callback_data max: 64 bytes
  • Format: batch:toggle:{csv}:{name} (13 bytes prefix + CSV + 1 colon + name)
  • Average container name: 6-10 characters
  • With 8 containers, CSV ≈ 48-80 bytes (approaching limit)
  • Rather than silent failure, enforce limit and guide user

Trade-off: Can't select many containers at once

Alternative: Store selection in workflow static data (complex, not needed yet)

Guidance: For larger batches, recommend "update all" or text commands

Why Immediate Execution for Non-Stop Actions?

Decision: Update/start/restart execute immediately from multi-select; only stop confirms

Reasoning:

  • Consistent with Phase 08-02 (action callback behavior)
  • Consistent with Phase 09-01 (batch command behavior)
  • Stop is dangerous (data loss risk); update/start/restart are recoverable
  • User already made selection → clicking "Update (3)" is explicit intent
  • Adding confirmation for all actions would slow UX

Context reference: Phase 09 CONTEXT.md specifies "batch stop needs confirmation"

What Changed

Modified Files

n8n-workflow.json:

  • Added "updateall" rule to Keyword Router (before "update" rule)
  • Added 13 nodes for update all flow
  • Added 22 nodes for multi-select flow
  • Updated Parse Callback Data with batch:* parsing
  • Added 7 routing rules to Route Callback (updateall × 2, batch × 5)
  • Connected flows to existing batch execution infrastructure

New Patterns Established

Callback data compression: Managing selection state within 64-byte limit Checkmark toggle UI: Visual selection feedback in button text Selection state in callback: CSV format for passing container list between callbacks

Integration Points

Upstream Dependencies

  • 09-02: Batch execution loop, progress display, summary formatting
  • 08-01: Inline keyboard infrastructure, pagination patterns
  • 07-02: Docker API access via socket proxy

Downstream Effects

  • Phase 10: May add "Select Multiple" button to container list keyboard
  • Phase 10: May adjust entry points or keyboard transitions
  • Future phases: Multi-select pattern reusable for other batch operations

Known Issues

None identified. Workflow structure is valid, all nodes connected properly.

Next Phase Readiness

Phase 10 (Polish & Audit) can proceed:

  • ✅ Batch operations complete (all 3 plans done)
  • ✅ Update all and multi-select flows tested (in code)
  • ⚠️ Manual testing recommended before Phase 10
  • Entry points for batch:mode can be added during polish

Suggested Phase 10 tasks:

  1. Add "Select Multiple" button to container list keyboard (link to batch:mode)
  2. Test all batch flows in live environment
  3. Adjust button text/icons based on UX testing
  4. Consider adding "Update All" to menu or status view

Blockers: None

Risks: None

Phase 9 Progress: 3/3 plans complete ✅ Next: Phase 10 - Polish & Audit

Reference in New Issue View Git Blame Copy Permalink