apache / apache/rocketmq-dashboard
Maintenance windows cannot be edited after creation
- Dominant language
- Java
- Stars
- 1.4k
- Forks
- 683
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 58
Description
## Problem
Maintenance windows (alert silences) can only be created and ended. Once a window is created, its schedule and scope cannot be changed.
The current UI exposes only an **End** action:
- If a maintenance window was created too short, the operator must end it and create a new one.
- If a recurring window's time zone, weekdays, or recurrence end is wrong, the operator must delete and recreate it.
- If the scope was too broad (for example, all instances instead of one instance), recreating the window creates a new record and loses the original creator information.
The backend also has no update endpoint: `AlertSilenceController` supports list, create, and delete only.
## Expected behavior
- An administrator should be able to edit an existing maintenance window:
- start/end time;
- recurrence type, time zone, weekdays, and recurrence end;
- domain, rule, instance, and label scope;
- reason.
- Editing should reuse the same validation as creation:
- end after start;
- valid recurrence time zone and bounded window duration;
- required recurrence end and valid ISO weekdays;
- bounded labels and reason.
- The existing record ID and creator should be preserved.
- Updates should be recorded in the operation audit log as an alert-silence update.
- The maintenance window list should provide an edit action that pre-fills the existing form.
## Why this matters
During a real maintenance period, plans often move. Extending a window by thirty minutes should be a normal edit, not a delete-and-recreate workflow that risks a gap in alert suppression and loses record provenance.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with AlertSilenceController and the existing creation validation to trace how maintenance windows are stored and audited. Then inspect the maintenance-window list and form for the edit entry point and prefill behavior. Done means administrators can update all listed fields while preserving the record ID and creator, enforcing creation rules, and recording an alert-silence update in the audit log.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend-api-design, full-stack
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100