fix: avoid progress bar oscillation during bulk actions#143
Merged
Conversation
1470b7b to
154b57f
Compare
The action handler on the index page wrapped each record in try/rescue/after, so the `after` clause broadcast progress: 1 after every record — making the active jobs nav flash between the partial and complete states across iterations. Drop the after clause and rely on the per-iteration progress broadcast, indexing from 1 so it reaches 100% naturally on the last record. On a halted/crashed run, the nav already cleans up via the :DOWN monitor on the task pid. Also switch from Enum.each to Enum.reduce_while so the loop actually halts on a record-level error, matching the "encountered an error and stopped" message that gets announced.
154b57f to
95cba7b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two related issues in the bulk action handler on the index page (
LiveAdmin.Components.Container.Index):1. Progress bar oscillation
The
handle_event("action", ...)handler wraps each selected record's processing intry/rescue/after, with theafterclause broadcastingprogress: 1for the job pid. Because that block sits inside theEnum.eachloop oversocket.assigns.selected,progress: 1is broadcast after every record — not once when the batch completes.The nav jobs LiveView (
LiveAdmin.Components.Nav.Jobs) treats anyprogress >= 1message as completion: it snaps the bar to 100% and schedules a:remove_job1500 ms later. Before that fires, the next iteration broadcasts a partialidx / count, which the handler matches by pid and resets the bar back down. Visually that's a progress bar oscillating between full and partial across the duration of the bulk action.Additionally, the body used
Enum.with_index/1(zero-based), so per-iteration progress was0/n .. (n-1)/n— the bar could never reach 100% from the body, only from the spuriousafter.2. Inaccurate error message
The per-record
rescueannounces"%{name} encountered an error and stopped"— but the surroundingEnum.eachdoes not stop. The loop continues processing subsequent records after an error, contradicting the message and (more importantly) running an action that has already proven unsafe for the current batch.Fix
afterclause entirely. WithEnum.with_index(1)and dividing by a hoistedtotal, per-iteration progress climbs1/n .. n/nand reaches 100% naturally on the last record. If the loop halts or the task crashes, the nav jobs LiveView already monitors the task pid and cleans up the entry on:DOWN.Enum.eachtoEnum.reduce_while, halting with:errorwhen a record raises. The final announcement (completevsencountered an error and stopped) is chosen based on the reduce result.Test plan
mix format --check-formattedpassesmix credopassesmix test test/live_admin/components/container_test.exs— 30/30 pass