Your services have been updated - Reload services

[leoheck]

Your issue

Hello guys!

Yesterday I started to see this. This is pretty nice actually.

Every time this appears, I reload the services. But this thing keeps appearing. I am not sure if it is a bug or if these files a constantly being updated. It they are being updated it is fine, I will deal with it since it is a nightly build. But I would like to say that this thing is appearing quite often. However, it may be a bug where the service files are not being updated or something.

Version I am using,

Cheers!

[vraravam]

@leoheck - could you please try this with the latest nightly? We are already on 55+

[vraravam]

Also - is this a duplicate of #204 ?

[leoheck]

Sure, I was just not upgrading it since the Messages announced on this New Feed were never saying something related to my setup on Linux. They were mostly addressing things on Windows/macOS, but this may not be right. Maybe there are some features being hidden in this feed.

See, it always shows things like "Other Changes" and maybe not the important changes.

[leoheck]

Also - is this a duplicate of #204 ?

I am not sure. I am going to install the latest nightly now and give you some feedback by tomorrow.

[vraravam]

We are using the autogenerated changelog and not manually calling out anything specific per se. That's why you might see only the section for "Other changes"

In the past couple of nightlies, we are have also upgraded electron to 19.0.4 (from 18.x) - so that is definitely an improvement across the board for all OSes - especially in the context of security fixes on chromium

[leoheck]

Got it. Then I will update more often for sure. Thanks @vraravam !

[SpecialAro]

Also - is this a duplicate of #204 ?

Yes, this is a duplicate of that issue. I now why this is happening and still haven't got the time for raising an issue about it.

Basically, Ferdium checks the API server for a new "signal" on whether there is a recipe new version or not. And then, instead of downloading the new version from the API server, it checks the local instance for a version mismatch again, and triggers an install of that version (local) again.

And then, after reload, it checks again for updates and the cycle starts again....

This needs correction :(

If you use the local server as an API (i.e. without an account) then this issue doesn't happen given the fact that the local server doesn't receive the version bump until you install a new Ferdium version.

[vraravam]

Basically, Ferdium checks the API server for a new "signal" on whether there is a recipe new version or not. And then, instead of downloading the new version from the API server, it checks the local instance for a version mismatch again, and triggers an install of that version (local) again.

And then, after reload, it checks again for updates and the cycle starts again....

nice deduction! I hadn't thought of this at all!

If you use the local server as an API (i.e. without an account) then this issue doesn't happen given the fact that the local server doesn't receive the version bump until you install a new Ferdium version.

Yes - that would explain why I never faced this problem. I switched to the serverless mode around the time I started contributing to Ferdi.

[SpecialAro]

Basically, Ferdium checks the API server for a new "signal" on whether there is a recipe new version or not. And then, instead of downloading the new version from the API server, it checks the local instance for a version mismatch again, and triggers an install of that version (local) again.

And then, after reload, it checks again for updates and the cycle starts again....

nice deduction! I hadn't thought of this at all!

I've checked the files and, in fact, this is what happens but I think it is unintended... It should download from the server the latest recipe. Although, there is a catch on that - sometimes recipes changes are also accompanied with an app change (i.e. a change done to Ferdium-App and also to Ferdium-Recipes at the same time, making the recipe dependent on functions exported as global on the app), which causes problems. I think that this issue needs a full review of the App - Recipe - Server integration process and that some rules need to be defined so that users can't have a problem with this.

A workaround that I thought is that we can expose at the server side the lastest working version of the app itself, which would be checked by the Ferdium-app before checking for recipes updates.
Then, if the user is running a version which is >= server exposed then it should go to the recipe upgrade feature (1). Otherwise, it won't check for recipe upgrades, and it would stick with whatever version of the recipe the internal server has until the user upgrades the app.

(1) In here we would still face the problem where the internal server will be running a latter version when compared to the API server, but this time, given that the recipe's version is higher, it won't force an update.

What do you think? Is there a better way to achieve this?

[vraravam]

That is good, but, imo a bit complicated - based on a different path, i had proposed the same for Ferdi - but that was shot down.

On the app, we will have to send both the recipe version as well as the app version. On the server, the server should know what's the latest version of the app that has been released (now this brings in further complication whether to support nightlies/betas as well as public versions). On top of this, the recipe version should be checked for the compatible version of the app vs recipe combination.

A simpler solution would be that we do not allow recipe upgrades on the server. Instead force the user to upgrade the app. This has downsides where users who dont want to upgrade to nightlies, but demand recipe fixes will keep logging bugs - for which we will end up responding "go to nightly or wait for a new version". imo, this is a catch-22 that we need to take a decision on either side and stick with it.

[SpecialAro]

On the app, we will have to send both the recipe version as well as the app version. On the server, the server should know what's the latest version of the app that has been released (now this brings in further complication whether to support nightlies/betas as well as public versions). On top of this, the recipe version should be checked for the compatible version of the app vs recipe combination.

Yes, there is this complication on checking different things before allowing a recipe upgrade. For solving the issue of supporting nightly/betas I think that can be solved with multiple instances of the API server (one for nightlies/beta and another for stable releases). This way, whenever the user clicks "Enable pre-releases" on Ferdium, it would change the API server to the nightly version of it. Here, there is a problem on wether we can use or not the same database on both servers just by mounting it in the docker.

A simpler solution would be that we do not allow recipe upgrades on the server. Instead force the user to upgrade the app. This has downsides where users who dont want to upgrade to nightlies, but demand recipe fixes will keep logging bugs - for which we will end up responding "go to nightly or wait for a new version". imo, this is a catch-22 that we need to take a decision on either side and stick with it.

This solution is, in fact, simpler to be implemented. We just have to disable recipes entirely on the server side and make sure the App stops trying to fetch for recipes upgrade. So that all recipes are managed only by the Ferdium App/Ferdium Recipes integration, and not through the server as well.

Do you have any idea how Franz implements this? Can we try to follow a similar approach?

[leoheck]

I haven't seen this anymore after the upgrade of version 56

[SpecialAro]

Reopening as the issue persists if you don't upgrade, as I said before.

[leoheck]

Cool, but sorry too much text. What is the point to use an outdated nightly version?

[SpecialAro]

Cool, but sorry too much text. What is the point to use an outdated nightly version?

It is not a problem now, per se. But it is a problem once we release stable versions.

Actually you can experience the same problem with the beta version, which should be stable, and the current server instance. This mismatch causes the issue....

A workaround as I said is probably releasing 1 server for stable + 1 for betas + 1 for nightlies with possibly shared databases. But that can be overkill.

[jason-mehmel]

A note here that I'm seeing this on the version I downloaded from Snap on Ubuntu 21.10

And I did register for a Ferdium account.

Maybe if I chose something other than Snap to get Ferdium?

[vraravam]

A note here that I'm seeing this on the version I downloaded from Snap on Ubuntu 21.10

@jason-mehmel - as @SpecialAro noted, this is prevalent for all installations of Ferdium which use any server (only the accountless/serverless option will be spared this issue).

[jason-mehmel]

But it's not a problem on the Nightly version?

Is that available via Snap?

[vraravam]

[jason-mehmel]

Thank you!

[SpecialAro]

This should be fixed now. I'm closing it. If it's needed we can reopen it.