apache / apache/rocketmq-dashboard

Maintenance windows cannot be edited after creation

Open
#3,165 1 comment 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.