[
https://issues.apache.org/jira/browse/NIFI-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132595#comment-18132595
]
Rob Fellows commented on NIFI-16502:
------------------------------------
[~vinz1968] This is an interesting concept, but from my perspective the UI-only
approach works for simple stateful flows, but it cannot reliably promise a
complete restoration.
# Stateless Process Groups are incompatible
NiFi does not allow their processors or Controller Services to be started
individually. The server must restore the group as one scheduling unit.
# It misses affected component types
Disabling references also disables Flow Analysis Rules, but the proposal
restores only Controller Services, Processors, and Reporting Tasks.
# Browser snapshots become stale
{{localStorage}} can survive logout, be shared across tabs or users, and
describe components that were later modified intentionally. A stale snapshot
could restart something an operator deliberately stopped.
# Restoration becomes a fragile distributed workflow
Every component requires a separate revision-controlled, cluster-replicated
request. Failures produce partial restoration with no transaction, rollback,
durable progress, or reliable retry boundary.
# The UI would duplicate framework logic
It would need to reconstruct dependency ordering, cycles, stateless-group
behavior, validation, permissions, and failure propagation. The server already
understands these rules and is less likely to drift.
# Cancellation and auditing are weak
Closing the dialog only stops polling; it cannot undo completed changes.
Individual audit entries also lack a shared restoration operation ID for
troubleshooting.
I'm not familiar enough with the complexities of what it might take on the
backend side if we were to build it out there. Maybe [~markap14] has some
insights into its viability.
> Restore previous state of referencing components when re-enabling a
> Controller Service
> --------------------------------------------------------------------------------------
>
> Key: NIFI-16502
> URL: https://issues.apache.org/jira/browse/NIFI-16502
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI
> Reporter: Vincenzo Lombardo
> Priority: Minor
>
> h3. Proposal
> Keep a snapshot of the referencing component states in the UI when a
> Controller Service is disabled, and offer an additional enable scope that
> restores it.
> * *Snapshot*: when the disable request is submitted, the dialog already has
> the full referencing component tree with the current state of each component.
> The UI stores the identifier, reference type and state of each referencing
> component in browser storage, keyed by the Controller Service identifier,
> using the existing StorageService with an expiration.
> * *Enable scope*: when a snapshot exists for the Controller Service, the
> Enable dialog offers a new scope such as _Service and previously active
> components_, showing when the snapshot was taken. Without a snapshot the
> dialog is unchanged.
> * *Restore*: the {{PUT /controller-services/\{id\}/references}} endpoint
> always updates all referencing components, so the restore uses the existing
> per-component endpoints instead:
> ** referencing Controller Services that were ENABLED are enabled with {{PUT
> /controller-services/\{id\}/run-status}}, waiting for each level to be
> enabled before the services that depend on it;
> ** referencing Processors and Reporting Tasks that were RUNNING are started
> with {{PUT /processors/\{id\}/run-status}} and {{PUT
> /reporting-tasks/\{id\}/run-status}}.
> * Components removed since the snapshot are skipped, and components added
> since the snapshot are left unchanged. The snapshot is removed once the
> restore completes, and the dialog reports which components could not be
> started.
> This requires no framework or REST API changes and keeps the current behavior
> when no snapshot is available.
> h3. Limitations
> * The snapshot only exists in the browser where the service was disabled. A
> service disabled by another user, from another browser or through the REST
> API has no snapshot, so the new scope is not offered.
> * Restoring N components takes N requests instead of a single request to the
> references endpoint.
> h3. Alternative
> A server-side option would be to let the references endpoint update only a
> given set of components, reusing the {{candidates}} support that
> {{StandardControllerServiceProvider.scheduleReferencingComponents()}} already
> has (introduced for NIFI-6748). The UI snapshot would then only choose the
> candidates, and the restore would remain a single request. Feedback on the
> preferred approach is welcome before implementation.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
