Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: OpenEMR development-easy docker on latest flex-edge not loading new class files #389

Open
adunsulag opened this issue Apr 12, 2024 · 3 comments

Comments

@adunsulag
Copy link
Member

Ran into an interesting situation and not sure if its a bug or if I've got something different going on.

I setup a testbed on AWS running the development-docker a slightly tweaked docker-compose.yml (domain email, and an additional service docker added). Everything was running great but I then did a git pull master from the openemr codebase and discovered none of the new classes in OpenEMR were being loaded.

Thought it was the opcache stuff we added and I tried clearing the cache but that didn't do anything. I went and looked at the composer autoloader and discovered that the openemr/vendor/composer/autoload_classmap.php was missing the new BillingFormType.php class which was the exception I was seeing thrown. Normally, composer would fall back to the filesystem and look for the file if it was missing from the optimized autoloader but I haven't been running into that behavior. What's odd is that my local docker environment is not experiencing this problem, only the aws images which is why I'm scratching me head on this issue.

Looking here: I can see we added an acpu option 9 months ago, but I would have thought people would run into this issue since then.

composer dump-autoload --optimize --apcu

I was able to work around the issue by just re-dumping the autoload after doing a git pull master:

composer dump-autoload --optimize --apcu

I'm wondering if we need to change up the way openemr.sh works so that we don't run an optimized autoloader on the development dockers. Its actually discouraged per the composer documents as optimize is meant for production workloads and not development.

I've attached the docker-compose file I was using to build the system (had to rename to txt to get it to upload) and changed the domain name/service name to keep confidential the customer for now.
docker-compose.yml.txt

@jesdynf
Copy link
Collaborator

jesdynf commented May 18, 2024

I'm reading this but not prepared to comment because I don't use flex and barely understand it.

I do know that flex's launch script is divergent from a regulat container's though. Is flex considered production-ready? Should the optimize just be yanked from it, or should we add a "development" envvar to the script that the compose yml could set for passthrough which controls optimize?

@bradymiller
Copy link
Member

That is odd since not using the --classmap-authoritative setting which would not look at the filesystem if not found in map: https://getcomposer.org/doc/articles/autoloader-optimization.md

We could definitely modify it to drop --apcu when in development mode in the flex series dockers though (or even not run composer dump-autoload completely if still getting weird behavior with that). Would use the setting "DEVELOPER_TOOLS" to control this.

@bradymiller
Copy link
Member

btw,
flex can be run in production mode or development mode. Production mode allows grabbing codebase from a git/github branch for custom code users, which is default setting if not using all the development setting bells and whistles. However, we all use flex in development mode since using all the development settings bells and whistles:
https://github.com/openemr/openemr/blob/master/docker/development-easy/docker-compose.yml#L34-L68

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants