Bug 509890 - Insufficient error handling; revision checks disabled during ItemModifyJob
Summary: Insufficient error handling; revision checks disabled during ItemModifyJob
Status: RESOLVED NOT A BUG
Alias: None
Product: kde
Classification: I don't know
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-09-24 20:32 UTC by jshand2013
Modified: 2025-09-24 20:59 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jshand2013 2025-09-24 20:32:40 UTC
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.
Comment 1 Nate Graham 2025-09-24 20:59:48 UTC
Please don't copy-paste the output of code "analysis" from ChatGPT or another AI. It isn't actionable. Submitting merge requests to change these things would be helpful, but bug reports pointing them out isn't.