[kde] [Bug 509889] New: RID operations broken because collection context resets before each command

[bugzilla_noreply at kde.org]

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

            Bug ID: 509889
           Summary: RID operations broken because collection context
                    resets before each command
    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: ---

OS Details:

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

# RID operations broken because collection context resets before each command

**Severity:** High  
**Area:** Server / ItemLinkHandler  

## Description
Autotest contains FIXME that all RID-related operations are broken due to
reseting the collection context before every command, which likely loses
required context for RID resolution.

## Evidence
/mnt/data/akonadi_extracted/akonadi/autotests/server/itemlinkhandlertest.cpp
lines 96–104 and 207–214:

```
  96|                   << TestScenario::create(5, TestScenario::ClientCmd,
Protocol::LinkItemsCommandPtr::create(Protocol::LinkItemsCommand::Link, 4, 6))
  97|                   << TestScenario::create(5, TestScenario::ServerCmd,
Protocol::LinkItemsResponsePtr::create());
  98|         QTest::newRow("non-existent item only") << scenarios <<
Protocol::ItemChangeNotificationPtr::create() << false;
  99| 
 100|         // FIXME: All RID related operations are currently broken because
we reset the collection context before every command,
 101|         // and LINK still relies on SELECT to set the collection context.
 102| 
 103|         // scenario.clear();
 104|         // scenario << FakeAkonadiServer::defaultScenario()
```

```
 207|                   << TestScenario::create(5, TestScenario::ClientCmd,
Protocol::LinkItemsCommandPtr::create(Protocol::LinkItemsCommand::Unlink, 4096,
6))
 208|                   << TestScenario::create(5, TestScenario::ServerCmd,
Protocol::LinkItemsResponsePtr::create());
 209|         QTest::newRow("non-existent item only") << scenarios <<
Protocol::ItemChangeNotificationPtr::create() << false;
 210| 
 211|         // FIXME: All RID related operations are currently broken because
we reset the collection context before every command,
 212|         // and LINK still relies on SELECT to set the collection context.
 213| 
 214|         // scenario.clear();
```

## Steps to Reproduce
1. Run `itemlinkhandlertest` with focus on RID-based operations.
2. Trace server command handling to verify collection context is reset before
each command.
3. Observe failures or unexpected behavior when linking/unlinking items by RID.

## Expected Behavior
RID operations should succeed while maintaining necessary collection context
across commands.

## Actual Behavior
RID operations fail due to lost context.

## Suggested Fix / Next Steps
- Ensure command handlers preserve or restore the correct collection context
across related operations.
- Consider explicitly passing context required for RID resolution rather than
relying on implicit persistent state.
- Add tests covering RID operations end-to-end.

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