[kde] [Bug 509890] New: Insufficient error handling; revision checks disabled during ItemModifyJob

bugzilla_noreply at kde.org bugzilla_noreply at kde.org
Wed Sep 24 21:32:40 BST 2025


https://bugs.kde.org/show_bug.cgi?id=509890

            Bug ID: 509890
           Summary: Insufficient error handling; revision checks disabled
                    during ItemModifyJob
    Classification: I don't know
           Product: kde
      Version First unspecified
       Reported In:
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: unassigned-bugs at kde.org
          Reporter: jshand2013 at gmail.com
  Target Milestone: ---

Operating System: openSUSE Tumbleweed 20250923
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.2
Kernel Version: 6.16.8-1-default (64-bit)
Graphics Platform: Wayland
Processors: 12 × Intel® Core™ 7 150U
Memory: 16 GiB of RAM (15.3 GiB usable)
Graphics Processor: Intel® Graphics
Manufacturer: Dell Inc.
Product Name: Inspiron 16 5640

# Insufficient error handling; revision checks disabled during ItemModifyJob

**Severity:** Medium-High  
**Area:** AgentBase / ResourceBase  

## Description
`ItemModifyJob` has `disableRevisionCheck()` calls with TODOs questioning
where/how to handle errors. Disabling revision checks risks overwriting
concurrent changes without detection.

## Evidence
/mnt/data/akonadi_extracted/akonadi/src/agentbase/resourcebase.cpp lines
691–696:

```
 688|     connect(transaction, &KJob::finished, d,
&ResourceBasePrivate::changeCommittedResult);
 689| 
 690|     // Modify the items one-by-one, because STORE does not support mass
RID change
 691|     for (const Item &item : items) {
 692|         auto job = new ItemModifyJob(item, transaction);
 693|         job->d_func()->setClean();
 694|         job->disableRevisionCheck(); // TODO: remove, but where/how do we
handle the error?
 695|         job->setIgnorePayload(true); // we only want to reset the dirty
flag and update the remote id
 696|     }
```

## Steps to Reproduce
1. Simulate concurrent modification to an `Item` while a resource executes
`ItemModifyJob` with revision checks disabled.
2. Observe whether conflicting updates are accepted without error.

## Expected Behavior
Conflicting updates should be detected and surfaced to the caller; revision
checks remain enabled or are replaced with safe conflict resolution.

## Actual Behavior
Revision checks are disabled; TODO indicates missing error handling path.

## Suggested Fix / Next Steps
- Reintroduce revision checks or implement optimistic concurrency with retries
and conflict callbacks.
- Plumb explicit error handling paths where jobs currently suppress errors.
- Extend autotests to cover concurrent modification scenarios.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the Unassigned-bugs mailing list