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

Jialiang Cai reassigned AMBARI-26625:
-------------------------------------

    Assignee: Jialiang Cai

> Complete React Background Operations and Config History parity
> --------------------------------------------------------------
>
>                 Key: AMBARI-26625
>                 URL: https://issues.apache.org/jira/browse/AMBARI-26625
>             Project: Ambari
>          Issue Type: Bug
>            Reporter: Jialiang Cai
>            Assignee: Jialiang Cai
>            Priority: Major
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> h2. Problem
> The React frontend has partial implementations of Background Operations and 
> Dashboard Config History, but their behavior does not yet provide a reliable 
> equivalent to the classic Ember UI. Request snapshots and realtime updates 
> use incompatible data shapes, task and host updates can be lost, operation 
> polling can overlap, task subscriptions and timers are not consistently 
> cleaned up, and native WebSocket failure does not reproduce the classic 
> SockJS fallback boundary.
> The existing popup also lacks complete permission, preference, abort, 
> terminal-status, Request Schedule, and error-recovery behavior. Some 
> scheduled action responses incorrectly treat {{RequestSchedule.id}} as a 
> normal request ID. Config History loads an incomplete client-side view rather 
> than the classic server-paged contract, loses the selected version when 
> navigating to Service Configs, and does not expose all association, 
> compatibility, timezone, sorting, filtering, refresh, or failure behavior.
> This issue covers the complete non-Metrics module defined by the classic UI 
> baseline. Metrics pages, charts, Heatmaps, Horizon Charts, widgets, and 
> Metrics APIs are not part of the scope.
> h2. Scope
> * Reconcile the recent request list as a REST snapshot and merge request 
> events as bounded upserts without losing unrelated operations.
> * Preserve the classic request fields, upgrade exclusion, running count, 
> status groups, progress, context, user, timestamps, duration, and Show More 
> behavior.
> * Load request hosts and tasks through the classic minimal-response contract 
> and add tasks or hosts introduced by request events.
> * Load task stdout, stderr, output/error log paths, and terminal status; use 
> dynamic task events while connected and serialized REST polling while 
> disconnected.
> * Clean up all module polling, reconnect, and dynamic subscription work on 
> status, dependency, route, modal, session, or application lifecycle changes.
> * Use one application STOMP client with the ten non-Metrics static 
> destinations and dynamic task destinations.
> * Use native WebSocket first, fall back to the classic SockJS transport list 
> after an initial native socket or STOMP failure, reconnect established 
> transports after six seconds, use ten-second heartbeats, and bound retained 
> messages.
> * Apply exact Cluster User restrictions, automatic/manual popup preference 
> semantics, {{SERVICE.START_STOP}} authorization, accessible Abort UI, 
> duplicate submission locking, failure recovery, success feedback, and request 
> refresh.
> * Preserve existing request progress entry points for ordinary 
> {{Requests.id}} response values and never use a {{RequestSchedule.id}} as a 
> request ID.
> * Read, display, and cancel source Request Schedules, expose the 
> pending-schedule query, and retain one-host Recommission suppression.
> * Replace Config History with the classic server paging, sorting, 
> filtered/overall totals, exact/match/relative-time predicates, field-specific 
> suggestions, and config-event refresh contract.
> * Show service, version, group, current state, hosts, author, notes, stack 
> compatibility, and creation time in the persisted user timezone.
> * Navigate eligible history records to Service Configs with the selected 
> service, group, and version; load the current default together with a 
> selected non-default version; preserve the unsaved-change guard and consume 
> transient history state.
> * Add focused tests for data reconciliation, status policy, transport 
> selection, schedule APIs, permission boundaries, task lifecycle, Config 
> History queries, error recovery, and selected-version navigation.
> h2. Classic UI Baseline
> The acceptance baseline is 
> {{docs/frontend-refactor/ember-baseline/02-background-dashboard.md}}, feature 
> IDs {{BG-001}} through {{BG-009}} and {{DASH-002}} through {{DASH-004}}. 
> {{DASH-001}} is an existing navigation fact, not a request to implement the 
> excluded Metrics page. The React gap analysis is recorded in 
> {{docs/frontend-refactor/react-current/02-background-dashboard-gap.md}}.
> The authoritative network comparison includes the classic AJAX definitions 
> and call sites, direct HTTP calls, browser network entry points, and realtime 
> inventory. The required contracts include:
> * Recent background request GET with its restricted {{Requests}} field list 
> and {{minimal_response=true}}.
> * Request details GET with request fields and minimal task fields.
> * Individual task GET for task state, stdout, stderr, and log paths.
> * Request PUT for {{ABORTED}} plus an abort reason.
> * Request Schedule POST, individual GET, pending GET, and DELETE.
> * Native STOMP WebSocket and SockJS endpoints.
> * Ten static non-Metrics STOMP destinations and dynamic 
> {{/events/tasks/{taskId}}}.
> * Server-paged service config versions GET, unfiltered total GET, and 
> field-specific suggestion GET.
> * Current and selected service config version requests used after history 
> navigation.
> h2. Acceptance Criteria
> * The recent request list converges correctly when REST snapshots and request 
> events arrive in either order, remains de-duplicated and sorted, excludes 
> upgrade requests, and does not grow beyond its visible bound.
> * Request, host, task, and log levels display their classic fields and 
> support failure, Retry, filters, status transitions, newly introduced 
> tasks/hosts, and lifecycle cleanup.
> * {{FAILED}}, {{SKIPPED_FAILED}}, {{TIMEDOUT}}, {{ABORTED}}, and 
> {{COMPLETED}} are terminal where appropriate; Pending includes queued work 
> and Success maps completed work.
> * A disconnected running task is polled without overlapping requests. A 
> connected running task uses its dynamic destination and unsubscribes on every 
> terminal status or when the detail view closes.
> * Malformed static or dynamic STOMP messages do not break the application.
> * Initial native socket or STOMP failure switches to SockJS 
> eventsource/xhr-polling transports. Established connection loss reconnects 
> after six seconds and restores subscriptions without claiming event replay.
> * Only the exact classic Cluster User role is restricted from Background 
> Operations. Manual Navbar entry remains available regardless of the 
> automatic-popup preference for eligible users.
> * Abort is shown only with {{SERVICE.START_STOP}} and an abortable status, 
> confirms before submission, locks duplicate attempts, sends the classic 
> payload, recovers on failure, and refreshes on success.
> * Ordinary 202 responses open the returned request. Scheduled responses open 
> the operation list and never request {{/requests/{RequestSchedule.id}}}.
> * A source Request Schedule can be read and cancelled while future batches 
> may run; disabled state is shown; one-host Recommission is not misrepresented 
> as a cancellable schedule.
> * Config History performs server paging and sorting, distinguishes filtered 
> and overall totals, applies classic predicate types, safely escapes and 
> encodes match values, and refreshes after config events.
> * Config History displays all documented non-Metrics association fields, uses 
> the persisted user timezone, and provides recoverable errors.
> * Deleted groups and uninstalled services are not navigable. Eligible rows 
> open Service Configs at the requested group/version, including historical 
> default and non-default versions, without bypassing unsaved-change protection.
> * Unit tests cover snapshot/event semantics, terminal and filter mappings, 
> schedule identity, transport URLs/fallback, permission and preference policy, 
> Abort failure recovery, task subscription cleanup, Config History query 
> construction, timezone, association display, config-event refresh, and 
> selected-version navigation.
> * Runtime validation covers real WebSocket/SockJS, reconnect loss, schedules, 
> permission roles, task logs, large request/config histories, pagination, 
> timezone, and selected config group/version loading.
> h2. Partial Cross-Module Boundaries
> {{BG-005}} remains partial until business-specific Retry eligibility and 
> commands are reconciled in Installer, Services, Upgrade, Kerberos, and HA 
> modules. The generic Background Operations popup must not guess or issue 
> those commands.
> {{BG-006}} remains partial until HSI pending-schedule conflict protection and 
> complete wizard/upgrade mutual exclusion are reconciled in their owning 
> modules. This issue provides the Request Schedule contracts and generic 
> cancellation behavior but does not claim those flows are complete.
> h2. Out of Scope
> * Metrics dashboards, Metrics tabs, Metrics widgets, charts, Heatmaps, 
> Horizon Charts, and Metrics data APIs.
> * Dashboard widget health summaries recorded as {{DASH-005}}.
> * Business-specific retry implementations owned by Installer, Services, 
> Upgrade, Kerberos, or HA.
> * Complete HSI, wizard, or upgrade scheduling mutual exclusion owned by later 
> modules.
> * A new universal REST replacement for every classic realtime mapper. Each 
> owning module must validate its documented snapshot and convergence boundary.
> h2. Compatibility Decisions
> The React implementation must not reproduce known unsafe or failure-prone 
> classic behavior:
> * Loaded task output is opened by assigning {{textContent}} to a {{pre}} 
> element rather than interpolating it through {{document.write()}}.
> * {{TIMEDOUT}} and {{SKIPPED_FAILED}} terminate polling and task 
> subscriptions rather than leaking them.
> * Missing tasks, unseen hosts/tasks, and malformed socket messages are 
> tolerated rather than dereferencing an absent Ember model hierarchy.
> * A Request Schedule ID is never treated as a request ID.
> * Match filter values are regex-escaped and URL-encoded before they enter an 
> Ambari predicate.
> * Native connection resources are deactivated before an initial-failure 
> fallback activates SockJS.
> These are intentional compatibility corrections, not missing parity.
> h2. Verification Boundary
> Static code and unit tests are not sufficient to complete this issue. Ten 
> feature IDs remain {{NEEDS_RUNTIME_VALIDATION}}, while {{BG-005}} and 
> {{BG-006}} remain {{PARTIAL}}, until the runtime matrix in 
> {{docs/frontend-refactor/react-current/02-background-dashboard-gap.md}} is 
> executed against a real Ambari Server, representative permission roles, 
> scheduled operations, proxy transports, large histories, and the later owning 
> modules.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to