[jira] [Updated] (NIFI-15696) Add Rebase operation for versioned process groups

["Pierre Villard (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/NIFI-15696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pierre Villard updated NIFI-15696:
----------------------------------
    Status: Patch Available  (was: Open)

> Add Rebase operation for versioned process groups
> -------------------------------------------------
>
>                 Key: NIFI-15696
>                 URL: https://issues.apache.org/jira/browse/NIFI-15696
>             Project: Apache NiFi
>          Issue Type: New Feature
>          Components: Flow Versioning
>            Reporter: Pierre Villard
>            Assignee: Pierre Villard
>            Priority: Major
>
> When a versioned process group is at version N with local modifications (state {*}LOCALLY_MODIFIED_AND_STALE{*}), upgrading to a newer version requires reverting all local changes first, then changing version, then manually re-applying every customization. This is error-prone, causes unnecessary downtime, and discourages users from upgrading.
> This change adds a "Rebase" operation that upgrades a versioned process group to a newer registry version while automatically preserving compatible local changes — analogous to git rebase.
> {*}How it works{*}:
> The rebase operation has two phases:
>  # Analysis (read-only): Computes a three-way diff between the local flow, the base registry version (N), and the target registry version. Each local change is classified as Compatible (will be preserved), Conflicting (same field changed both locally and upstream to different values), or Unsupported (change type not yet supported by a rebase handler). Rebase is only allowed when all local changes are compatible.
>  # Execution: Deep-clones the target version snapshot, overlays compatible local changes onto it to produce a merged snapshot, then synchronizes the process group to the merged snapshot using the existing FlowUpdateResource async infrastructure. The VCI is set to the clean target version so that subsequent state checks correctly report LOCALLY_MODIFIED.
> Supported change types (for this first iteration, this will evolve over time):
>  * POSITION_CHANGED, SIZE_CHANGED, BENDPOINTS_CHANGED — cosmetic, always compatible (local wins)
>  * PROPERTY_CHANGED, PROPERTY_ADDED — compatible unless upstream changed the same property on the same component to a different value (convergent changes where both sides set the same value are accepted)
>  * COMMENTS_CHANGED — compatible unless upstream also changed comments on the same component
> Unsupported change types (examples: COMPONENT_ADDED, COMPONENT_REMOVED) block the rebase with a clear message. The handler architecture is extensible — adding support for a new change type requires only implementing a single RebaseHandler class.
> We follow a similar approach as what already exists for the new API endpoints:
>  * GET /versions/rebase-analysis/process-groups/\{id}?targetVersion=\{version} 
> returns the three-way analysis
>  * POST /versions/rebase-requests/process-groups/\{id} 
> initiates async rebase execution
>  * GET/DELETE /versions/rebase-requests/\{id}
> polling and cleanup (reuses FlowUpdateResource)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)