Couple of Problems With Latest Version

[cryoaura]

Hey everyone!

We have been using a version 3 (I think?) for a while now. The main page says api version "6.3.8.0" the login of the backend says 2.0. This version has been working great. We installed via Docker and everything worked fine. The problems came with upgrading to 4.0.4.

We ran into issues on the upgrade itself talking about foreignkey restraints being an issue, and then issues with identity. In the end, given the problems, we decided to just roll up a new install and manually move everything over. In this new setup, we decided to go with no docker, and so we installed Fusio 4.0.4 into an nginx php-fpm setup. It took a while, but we got everything working great except for one thing - The PHP worker.

So the first issue came with trying to get a worker operating. The source on github for it has what I thought were all the files needed, but the worker doesn't work, complaining about missing files. There was no vendors folder for the worker in the source. After fighting with moving the main fusio's vendor folder over, but it still failing, we just ripped the directory from the existing docker installation. We were able to point the existing 3 server to that worker, and it worked.

So first question is, how do we install the php worker without docker?

The second issue we're having is with the new 4.0.4 fusio, we setup the worker in the config file, but every time we try to create and execute a PHP-Worker action, it feeds us back this error:
"It looks like there is no worker configured for the language: php. Please add a worker to the configuration file"

Our config has this uncommented at the top of it:
'fusio_worker' => [
'php' => 'localhost:9992'
],

Is there a bug and something we can do to fix the utilization of workers in 4.0.4 fusio? If not, is there something I can provide to help troubleshoot?

Thanks in advance!

[cryoaura]

Oh also, the "." character is no longer allowed in usernames, which we use constantly! Is that something of a security concern that was removed? Can we get that back?

[chriskapp]

Hi @cryoaura thanks for the feedback, so in general you can easily run the PHP worker with a simple webserver like Apache or Nginx, you only need to create a dedicated domain for the worker and point it to the public/ folder s. https://github.com/apioo/fusio-worker-php. You of course also need to run composer install to install all dependencies for the worker, this creates also the fitting vendor folder. At you Fusio instance you then need to enter this domain at the worker array.

Regarding the dot at the username, this was indeed no intentional change, with the 4.0 version we have added an additional validation layer at our services and a dot was not included in this rule, I have just added a fix to allow the dot at the username again s. apioo/fusio-impl@ea5c132

In general regarding the worker setup we currently planing to redesign the worker system for the next 5.0 major version. We thinking about making our worker compatible with a function as a service provider like AWS lambda, so that you can easily run and scale your action code, so if you have in general some ideas or issues regarding the worker system then please let me know then we could consider this for the redesign.

[cryoaura]

I should have known from seeing the composer.json, that's just a major oversight on my end. That got the worker fired up and seemingly operating, however, fusio still just doesn't want to reach out to the worker despite configuring it in the config file. We are still getting: "It looks like there is no worker configured for the language: php. Please add a worker to the configuration file." despite use having it in there.

Any ideas why it wouldn't be seeing it in the configuration file? We have this in there:
'fusio_worker' => [
'php' => 'localhost:9992'
],

It's almost like it's caching the initial configuration and not reading file changes, but restarting php-fpm or nginx doesn't help.

As far as the worker system, honestly we have been very happy with how it's operating as it was made. I could see value for others though with an integration into Lambda or Azure, but as long as we are able to have locally hosted workers in php and python, we think that's awesome. The only thing that would be nice is giving the workers themselves the ability to call an action from an action. It seems to be the only thing missing we would enjoy. At this point, we separate the different actions, but actually just make an include to the file. It'd be more streamlined to be able to call another action from a worker action without doing an include or creating a route and calling it that way. It seems this is in the php api, but just not a part of the php worker.

The work you have done on this is awesome. Great job!

[cryoaura]

Alright, so this morning it just started acting like it now reads the configuration. This makes me suspect some sort of caching of the config, but I don't know if this is somehow on my end on something I messed up or if it's a setting in Fusio. Looking forward to hearing ideas!

[cryoaura]

For anyone curious on the configuration.php file changes not taking effect - it appears to cache, maybe by design? There's a cache folder in the fusio folder, and container.php in there that contains all those settings. So changing worker settings or token expiration requires a deletion of the container.php file INSIDE the cache folder, not the actual container.php file. On next load, it will regenerate with the new settings.