N
yeah forgot to mention that in the changelog, given the low feedback on the webdav integration, I didn't expect it to be used much at all. So the previous version had a longstanding bug essentially where only the user's home was exposed via webdav but not group folders nor shared items. This was the fix to introduce new toplevel items:
@timconsidine so if you don't care about the changelog as such, you could just put a string there, which will be reused or maybe better some https://foo.bar/changelog link which then would have some info on the ongoing changes. The UI should render the link clickable. Only the file:// triggers the loading of that from the folder and checks for the section with the version info.
Most likely someone runs a script against one of the apps which are integrated via LDAP then. Maybe a quick check can be to stop one after the other and see which one is causing the flood. Otherwise I think currently there is no way to see the origin for that unless we patch the code.
I did sync a folder tree here with rclone also just fine, but I think maybe the issue is actually that cubby now has one extra folder structure in webdav. It used to only expose the users's home folder, but now Home is one folder next to Groupfolder and Shares. I can see that for example MKCOL /webdav/kdj/Literatur/ does not have /webdav/home/.... so maybe just the rclone config needs to be adjusted?
Not too sure what the feature here would be, but once connected, the app exposes address books individually already, so in davX or thunderbird or so, you can then select which address book should be synced.
Or is this some other feature which is asked for?
Yes the format is described in https://docs.cloudron.io/packaging/manifest#changelog
Using the .md extension is not really relevant, however it might render the file better in git hosting apps.
There were recent fixes in webdav to be more compatible with windows, but that isn't released yet. Will see if this is already fixed and then cut a cubby release.
This is now fixed with https://git.cloudron.io/platform/box/-/commit/f30482808bc52c1f851fe6f01eef3f6b6dcea417
I was able to reproduce the issue of not being able to open existing files, but new files work just fine. The main issue I found was that all existing documents strangely use a different access path. They all container ../dist/v8/... in their path, while new documents are at .../dist/v9/... the v8 calls all return 404, which seems to be the root cause.
Does anyone know how those e2e documents reference actual api versions? I wasn't able to find anything related to this upstream.
Digging around the roundcube code, I found that the session garbage collector is called at https://github.com/roundcube/roundcubemail/blob/master/program/lib/Roundcube/rcube_session.php#L226 only, however as mentioned this is all very roundcube internal, so I guess one try is to see if the sessions get purged if you restart the app and maybe only then? Though but even if this is the case, I can't see anywhere in roundcube to change this behavior, so there might not be much to be done from a packaging perspective then 
Do you have any custom configs on that app? Like maybe increased session lifetime or so?
We are no experts on roundcube internals to know what may or may not work here, especially since we cannot reproduce it. So any extra info helps.
Given that you got a 400 status code error, did penpot server logs reveal anything about this?
That is intentional behavior. Given that task info is very little data as such, this is unnecessary microoptimization with the downside of essentially losing audit logs from the past.
On a modern system having tables with 10ks of rows in mysql should really not be an issue. How that would result in constant disk I/O without actually doing much, seems I think unrelated? If this is causing such high disk I/O I think maybe something is off in the mysql server settings instead. Do you have more analysis or info on that buffer pool activity relating to the tasks table?
So the observation is correct as such that each healthcheck call is also creating a session in the database. Given the lack of a real healthcheck route in roundcube itself https://github.com/roundcube/roundcubemail/issues/8372 this is actually not a bad thing to test the app for real by also testing db access here. Querying some static assets isn't really what we want to check for in apps.
Now there are two things, one is that roundcube has a session garbage collector at https://github.com/roundcube/roundcubemail/blob/master/program/lib/Roundcube/session/db.php#L199 which appears to be called just fine in all (many years old) instances I have access to. So the sessions will accumulate but then get purged, which is what we actually expect. Can you check how many session records your instances actually have in the database?
I cannot really reproduce this on 9.1, but there was no specific fix implemented recently.
There is a lot of information here, but I think it got all a bit too mixed together making it unclear what might actually case the disk I/O. For a start, upserting sessions in mysql does not mean it would sync to disk all the time, so this may or may not be related. Also it is unclear to me when and why how much disk I/O is expected and when it is an issue. So it becomes even harder to properly respond here.
Maybe we can try to separate the issues mainly first focusing on the potentially unnecessary session creation by the healtheck and that also ideally one application at a time. Maybe you can create those issues at the individual app packages to track those better, otherwise those issues easily get lost until such time we have resources to look into those.
Oh those cloudrons seem to have fetched the update info previously and didn't catch the jump directly to 9.1.3. Going first via 9.1.2 is harmless though.
