feat: add api to get information about diskspace usage of database. (jsonrpc method: get_storage_usage_report_string)

[Simon-Laux]

new jsonrpc api: get_storage_usage_report_string(accountId)
new rust API: get_storage_usage(&context)

This pr should help us in debugging issues like #7345

---

it also is part of output of Context.get_info(), but in my test it seemed to slow desktop startup,
so we may want to remove that and instead make PRs to the UIs to fetch the pretty formatted report from the jsonrpc api.
and do whatever makes most sense with it:

• call it and log result
• new screen to show the text
• or just a button to copy the report to clipboard, so users can send it to us easily.

[hpk42]

Hum, the stated rationale of this PR sounds a bit like "could be useful to debug storage issues", but as it involves cross-platform UI work, and there is no corresponding UI PR, it's thin. FWIW I agree excessive storage use needs debugging, but maybe some external script/tool that just goes to core's sqlite and does some analysis, is sufficient, and can be done without any cross-team synchronization.

…

On Fri, Nov 21, 2025 at 15:34 -0800, Simon Laux wrote: new jsonrpc api: `get_space_usage_report_string(accountId)` new rust API: `Context.get_space_usage()` it also is part of output of `Context.get_info()`, but in my test it seemed to slow desktop startup, so we may want to remove that and make prs to the UIs to fetch the pretty formatted report from the jsonrpc api. and do whatever makes most sense with it: - call it and log result - new screen to show the text - or just a button to copy the report to clipboard, so users can send it to us easily. This pr should help us in debugging issues like #7345 You can view, comment on, or merge this pull request online at: #7486 -- Commit Summary -- * feat: add api to get information about diskspace usage of database. -- File Changes -- M deltachat-jsonrpc/src/api.rs (7) M src/context.rs (5) M src/lib.rs (1) A src/space_usage.rs (124) -- Patch Links -- https://github.com/chatmail/core/pull/7486.patch https://github.com/chatmail/core/pull/7486.diff -- Reply to this email directly or view it on GitHub: #7486 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[link2xt]

but as it involves cross-platform UI work, and there is no corresponding UI PR, it's thin.

In the current state PR adds the information to the context info, it is already displayed on Android at the top of the log, so no changes are required. Dedicated API is not used and can probably be removed, but it is also not a problem.

[link2xt]

but maybe some external script/tool that just goes to core's sqlite and does some analysis, is sufficient, and can be done without any cross-team synchronization.

The problem is mostly on Android and if you look at the original issue, it is very unlikely that users will run this tool: #7345
It is repeated for years, users report a problem and then as soon as they find a workaround (e.g. removing the messages manually) they don't follow up, don't send any more logs and likely don't respond to any questions.

[hpk42]

On Sat, Nov 22, 2025 at 10:31 -0800, l wrote: link2xt left a comment (chatmail/core#7486) > but as it involves cross-platform UI work, and there is no corresponding UI PR, it's thin. In the current state PR adds the information to the context info, it is already displayed on Android at the top of the log, so no changes are required. Dedicated API is not used and can probably be removed, but it is also not a problem.

K, seems i got wrongly triggered by the added jsonrpc API here. If a jsonrpc API is not required, let's not introduce it. One thing less to worry/consider.

[Simon-Laux]

If a jsonrpc API is not required, let's not introduce it. One thing less to worry/consider.

the jsonrpc api is better:

• easy to add a simple button to copy the returned string to clipboard
• jsonrpc apis have close to no cost. especially this one which only returns a string and is not machine readable, so we can change output at any time.
• when we are not limited by time (get_info needs to be fast, jsonrpc apis don't), then we can also do data collection operations that are slower:
  • like checking size of every blob on disk, to show the largest blob files
  • or analyzing and showing how much space the blob de-duplication saves
  • and so on...

adding it to get_info has the following downsides:

• risk of slowing desktop startup
• get_config output gets formatted differently on desktop than on android so it would look ugly on desktop.
• not easy to copy for users

So I want to remove it from get_info and only keep the jsonrpc api to get the report as formatted string.

As stated in the updated pr description there are many possibilities to what the UIs can do with it, all of them are just displaying or offering to copy formatted text, so the PRs will be VERY EASY and probably could even be under 10 lines of code (copy button). Also this is only needed by android for now, and when we only have a jsonrpc API instead of calling it every time we run get_config then it won't affect the other platforms at all until they decide to use the API as well.

[r10s]

first, i agree info about usage is welcome

then, why is get_info() called on startup?

ftr, get_info() was always meant as debug info for devs. it was never meant to be show formatted to the user as currently in the about dialog - we just never came to doing that differently, as not important enough, but it should also not be a used as a reason to manifest that usage

so, maybe remove the formatter output on desktop alltogether and add a "get debug info" button

i am also sceptical in introducing more ways for the user to gather information. more to explain and to go wrong. already current info/log differantiation is more complex than on mobile. on android/ios getting the log anyways takes some time, so having a moment more does not make much of a difference. how long does getting the information really take currently?

[Simon-Laux]

Update:

• adding it to get_info makes the python CI fail
• link2xt told me that it should be part of log, so that users always share it when giving us the log. (so no dedicated/seperate action/screen/copy-button)

So plan is now remove from get_info and keep the jsonrpc method. then in UI call the method and prepend the space usage report to the start of the log.

[Simon-Laux]

why is get_info() called on startup?

it is called when you switch accounts so that it gets added to the logfile. If we want to change that, then we should make an issue on desktop repo and discuss it there.

[link2xt]

why is get_info() called on startup?

It is called on selectAccount and printed to the terminal, probably should not really be done, it just slows down account selection and user can anyway access this info from about window. EDIT: opened deltachat/deltachat-desktop#5755

But regardless of that, diskspace should not go into get_info anyway because everything else there is currently a bunch of single-line values, not a huge report. As it is placing huge multi-line string breaks legacy python test that parses get_info() by splitting it into lines and then by =.

UI-wise on Android nothing will change, but it will need to call not only get_info but this new API and put it at the top of the log, so users who normally don't care and just send us a text file will also have this report in the .txt already.

[link2xt]

LGTM expect for the naming and MsgId represented as usize in the public API.

[hpk42]

On Sat, Nov 22, 2025 at 11:02 -0800, Simon Laux wrote: Simon-Laux left a comment (chatmail/core#7486) > If a jsonrpc API is not required, let's not introduce it. One thing less to worry/consider. the jsonrpc api is better:

maybe, but that wasn't my concern here. Which UI required this API? We don't just add arbitrary buttons to UIs, even if it's super easy to do so.

[link2xt]

Which UI required this API?

Android has this merged: deltachat/deltachat-android#4060
No buttons, the info is just attached to the top of the log.