Skip to content

I20260503-1800

I20260503-1800: Fix progress overshoot >100% in Synchronize refresh jobs
@FoxyBOA FoxyBOA tagged this 03 May 15:52 
In RefreshSubscriberParticipantJob.doRefresh and the sibling
RefreshModelParticipantJob.doRefresh, the same IProgressMonitor was
passed sequentially to two consumers (subscriber.refresh +
SubscriberSyncInfoCollector.waitForCollector, and context.refresh +
JobManager.join respectively). Each consumer treated the monitor as
exclusively its own and reported its full budget against the parent,
which is how the JobManager group ends up displaying 115-160 % for
Synchronize jobs (reproducible with Subversive and other team providers).

Wrap the parent monitor with SubMonitor.convert(monitor, 100) and split
80/20 between the two consumers, mirroring the existing 80/20 split
already used in RefreshParticipantJob.initialize between
setProgressGroup(group, 80) and handleProgressGroupSet(group, 20).

To keep the production class shape unchanged and avoid touching
SubscriberSyncInfoCollector, the SubscriberJob exposes the existing
collector handoff as a small protected seam:

    protected void waitForCollector(IProgressMonitor monitor) {
        getCollector().waitForCollector(monitor);
    }

The regression test (RefreshSubscriberParticipantJobProgressTests in
org.eclipse.team.tests.core, wired into AllTeamTests) overrides this
seam in a TestableJob to imitate a greedy collector. With the previous
code the parent monitor records ~2000 ticks; with the fix it records
~1000, well below the 1500 threshold the test asserts.

Fixes #2645

Signed-off-by: boa <foxyboa@gmail.com>
Assets 2
Loading