friendica - Link zum Originalbeitrag

Stability of 2025.02-dev


Hey guys, as the February release is coming upon us fast - how stable is the development branch at the moment. There seem to be many big changes under the hood that need to be stabilized till Feb.

How safe is it to change to the develop branch at the moment.

E.g. @Michael Vogel is usually developing on one of his installations, but does not update because of these big changes.

!Friendica Developers

Als Antwort auf Tobias

@Tobias @Michael Vogel I use the develop branch and see not other errors in the admin log page, except of what I always see. ( alert: allowed memory size exhausted etc..) .. using php 8.4.2 .. but my instance is single user. so not so much going on, maybe. it currently works for me. I have only changed my daemon.{start|status|stop} scripts because of a deprecation message.
Als Antwort auf Tobias

@Tobias I'm not sure what you expect me to reply with this passive-aggressive tone, but none of the recent refactoring changes are intended to be breaking changes.

The fact that the develop branch has been mostly stable up to recently is more an outlier than what should be expected at all times. We do warn Friendica administrators the develop is risky, and the general absence of issues doesn't change this assessment.

Since the author of the recent refactoring doesn't run a node themselves (which they aren't under any obligation to do), then someone™️ needs to run these changes on their own node to test them in the wild, which I'll always be grateful for. And I won't look down on admins opting out of the develop branch either temporarily or permanently.

Als Antwort auf Hypolite Petovan

Since the author of the recent refactoring doesn't run a node themselves (which they aren't under any obligation to do), then someone™️ needs to run these changes on their own node to test them in the wild, which I'll always be grateful for.

For information only: I do run 2 test servers, but not as productive as I would like. (Server 1 -from which I post atm- runs 2024.08, server 2 runs develop branch) I will have to shut down my mastodon server in the next 3 months and my plan is to switch to #Friendica. But before that I would like to have more insight and quality in the code so I can trust it. That's why I'm heavily pushing the refactoring.

One can follow the refactoring here: github.com/friendica/friendica… And one can make sure that the refactoring shouldn't break anything. The only thing that was a BC break should be in the App class as mentioned. The logic was moved into an AppHelper and replaced DI::app() with DI::appHelper(). All official addons are adjusted. This only might break 3rd-party addons. And to solve this problem in the future I propose to add an BC promise, see github.com/friendica/friendica…

tl;rd:
- The quality was improved (much less warnings)
- If one is using the App class, use the dropin-replacement using DI::appHelper()
- There should no more breaking changes, switch to develop should be unproblematic.

Friendica Developers hat dies geteilt.

Als Antwort auf art4 test-account

I tried out develop as of cd79d26ed5. I'm finding that my addons are broken. It seems that loadHooks() is not being called in the worker, now that it's a console command. I haven't dug any further than that. It could be that it's already been fixed, although I don't see any commits along those lines. Or is this a deliberate decision and the addons should be adapted? The two hooks I most need are post_remote and post_remote_end.
Als Antwort auf Matthew Exon

Not sure about the exact addon that might has broken I looked at the mailstream addon:
git.friendi.ca/mexon/friendica…

The addon uses the old Friendica\App. Replace it with Friendica\AppHelper like this:

// Line 9: replace
use Friendica\App;
// with
use Friendica\AppHelper;

// Line 72 replace
function mailstream_addon_admin(App $a, string &$o)
// with
function mailstream_addon_admin(AppHelper $a, string &$o)

// replace all other type hint occurences

Friendica Developers hat dies geteilt.

Als Antwort auf art4 test-account

I will do that, and that makes sense, but I'm pretty sure it's not related to this particular problem.

When a worker retrieves an RSS item and creates a new item from it, it should call post_remote. And in general, workers should call a bunch of hooks in different contexts. But without loading the hooks, it never will do that. It should be fairly easy to experimentally confirm this, with anything that an addon has to do in a worker. Or even just by logging the hooks that get called without even activating any addons.

I was wondering why this isn't causing more obvious problems, then I realised that "normal" AP items arrive as a push. It's usually only RSS feeds that get pulled by a worker.

I think I'll probably have to look into this a bit more, but it'll take time.

Als Antwort auf Matthew Exon

I'd like to look deeper into this issue on git.friendi.ca, but I cannot register an account. 🙈


Account at git.friendi.ca


@Friendica Developers Is there someone with admin privileges from git.friendi.ca? I've tried registering my account many times but I never received the activation email so I cannot activate my account. I already tried it with different emails, looked into spam and so on.

Could someone please activate my account "Art4" or check why I don't receive any emails? Thank you!


Friendica Developers hat dies geteilt.

Als Antwort auf art4 test-account

It is related to the App -> AppHelper refactoring, for sure. What used to happen was this stack trace:

#0 /var/www/friendica/src/App.php(322): Friendica\\Core\\Hook::loadHooks()
#1 /var/www/friendica/src/App.php(289): Friendica\\App->load()
#2 [internal function]: Friendica\\App->__construct()
#3 /var/www/friendica/vendor/level-2/dice/Dice.php(132): ReflectionMethod->invokeArgs()
#4 /var/www/friendica/vendor/level-2/dice/Dice.php(96): Dice\\Dice->Dice\\{closure}()
#5 /var/www/friendica/src/DI.php(79): Dice\\Dice->create()
#6 /var/www/friendica/src/Core/Worker.php(536): Friendica\\DI::app()

Worker.php no longer calls app(), it calls appHelper(). I guess the dependency injection library doesn't realise that loadHooks() is supposed to be called during initialisation? All this dependency injection magic is where I get very lost. Quite likely you could eyeball it and figure out how initialisation of the hooks is supposed to happen.

#1 #2 #3 #4 #6 #5