Cloudron Forum

Late to the thread... "body": "{"skipBackup":false,"appStoreId":"com.paperlessng.cloudronapp@1.60.7"}", So this line indicates that the paperless app was in package version 1.60.7, which is the latest. "message": "Downgrades are not permitted for apps installed from AppStore or Community. force to override" The backend checks for updates periodically. It has a cache and passes on the cache to the frontend (for UI/display purposes). To prevent a race, eg you might have parallel tabs or another updated the app, the frontend passes back the version field to the backend before starting an update. What has happened here is that this cache is for some reason an older version and when it tries to update, the backend says that it's already updated to a more recent version. This issue is mostly caused by either a frontend caching or the backend unable to reach the appstore. I don't think it's the latter because the cloudron-support diagnostics came out clean . Usually, you can also clear this cache by clicking 'Check for updates'. I guess we have to debug further if someone gets this reproduced .

@timconsidine thank you for the link, that is the piece I was missing. I had been guessing at packages/releasebell and cloudron/releasebell; the group is apps, which I never tried. It does not get me all the way there, though. Signed in as LoudLemur the path 404s, and GitLab answers 404 rather than 403 for a private project you are not a member of, so I read that as the repository being there and my account not being on it. The apps group is public but lists no public projects, and packages lists exactly one, so I assume that is simply how app repos are kept rather than anything to do with me. @girish that narrows what I asked for in my last post. I no longer need the path, only access to apps/releasebell for LoudLemur, or a fork pushed somewhere I can reach. Everything else on my side is unchanged: once I can read the real tree I will rebase onto current master, re-run my checks against that base instead of the archived 1.12.0 mirror, and open the MR. Incidentally the footer of the notification email points at git.cloudron.io/cloudron/releasebell, which is one of the paths that comes back not-found. Small thing, but the in-app link looks stale relative to apps/. Happy to fix it in the same MR. On the email rule: you are right that it works, and more cleanly than I would have guessed before looking. The subject is built as <project> <version> (prerelease) released, and that (prerelease) comes straight from the release API flag rather than from pattern-matching the tag, so a filter on that literal string catches exactly the prerelease mails and nothing else. No false hits on a project that happens to ship a version called beta. So it is a good workaround and worth having posted for anyone who needs one today. Three things it cannot do, which is why I still think the setting earns its place. It is all-or-nothing. The reason I ended up adding a per-project override on top of the per-user flag is that the useful setting is not "no prereleases" but "prereleases for the four projects I actually test against, and not for the other forty". Expressing that as mail rules means one rule per project, edited by hand every time you follow something new. It deletes rather than defers. Because a suppressed release stays notified=FALSE in the database, turning the setting back on delivers the prereleases you missed while it was off. That is deliberate, and it is what makes the setting safe to flip. A filtered email is gone. And it depends on a presentation detail. The subject string is template text, not API surface. If someone rewords it, the rule quietly stops matching and you start receiving prereleases again, or a reworded rule quietly starts eating real releases. Filters that fail in the delete direction fail silently. None of which is an argument against your rule in the meantime.

@Joseph , yes, waiting for Cloudron 10 makes sense in this case, thank you!

@girish Following up on this one for PostgreSQL, since you're in that code anyway: shared_buffers there is still at the built-in default of 128 MB, on a service that had a 4 GB limit here. shared_buffers 16384 (8kB) = 128 MB effective_cache_size 524288 (8kB) = 4 GB (also the built-in default) work_mem 4 MB Postgres leans on the OS page cache far more than InnoDB does, so this is less dramatic than the MySQL case. But the usual guidance is somewhere around 25% of available memory, and 3% is a long way below that. effective_cache_size is a planner hint and is also left at its default, so it does not track the limit either. Would the same clamp you just added for MySQL make sense here, with a smaller fraction?

@fbartels I think the idea of moving more towards security is good. There is still much more to discover and implement there.

@roliG said: So having a working 1-Click install is always useful! Cloudron lets you install two applications gratis.

Ha ha ok, I misunderstood @james it seems https://downloads.metabase.com/v0.63.5/metabase.jar is available , so we may have to create a manual MR .

My experience with ChatGPT has been.. spotty at best. I'm glad you figured it out!

Even internal name collisions

Hello @loudlemur Unfortunately I can't do that. Due to license constraints and other things we currently are not looking for contributions to platform code.

yes, direct url is working again. That was it! Applied the one line change on all three servers here and the 60 query test goes from 20/60 to 60/60 on each of them. For reference, temperror was running at 48%, 34% and 18% of inbound mail over the last 24 hours on those three. I will report back once enough new mail has come in to see where it lands. Thanks for digging into this so quickly.

@necrevistonnezr the magic of CI/CD.

@ekevu123 Then you may not have understood. It makes no OS level changes. It works, which is why Docker acquired their company, technology and people. Single package & config change and App restart. Then you can run docker inside a Cloudron app container running sysbox-runc runtime (DinD) and more. Including Gitea runners. Up to you.

yes. I would not be surprised if the hickup comes from somewhere in the sql file. For the restore test you should first reset the failed migration to its previous state and extract the sql file from the old backup. There are instructions in the cloudron documentation for this.

@joseph That is it (source: I just tried it myself and directly deleted the app again)

From my understanding the sync bundle is less moving parts and can work without the s3 bucket. But I haven’t looked to close into your repo yet, so I cannot say how you have solved this part. I’m a long time Anytype user. But I have a subscription with them, so I am not an immediate candidate for a migration.

Great, and thanks girish. Cloudron is brilliant!

Hello @oauth2-tmp-cloudron-1784273754379-im6vnh Please see https://forum.cloudron.io/topic/14812/vaultwarden-fails-to-start-after-update-db-migration-error-sso and apply the fix.