Bug 509889 - RID operations broken because collection context resets before each command
Summary: RID operations broken because collection context resets before each command
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:30 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:30:32 UTC
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.
Comment 1 Nate Graham 2025-09-24 20:59:39 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.