kobaltzPRO

When you ssh into the EC2 instance, try doing this to get the database created.

sudo su
bundle exec rails db:create
exit

I believe they've changed the permissions of the ec2 user and you cannot login as the www user.

I think that it depends on the goals of the service object. If it were only internal interactions then this would make sense. However, if the issue was an error with an external api that you've wrapped your service object around, I would probably prefer this method.

That is indeed very strange! I just reprovisioned my development environment this morning and tested this with the latest Rails and devise. It is happening to me too! I'm guessing that when the generator is being ran, it is injecting the RAILS_ENV as an attribute and devise is picking it up somehow... Really weird!

Using this works without adding in the weird ENV

gem 'devise'
run 'bundle install'

generate(:scaffold, 'user', 'name')
generate('devise:install')
generate('devise','User')

I've entered an issue on Github regarding this issue. It is definitely unexpected behavior. However, I don't know how critical it is since there is a workaround.

https://github.com/plataformatec/devise/issues/4992

Try rebooting. also you can tail -f ~/Library/Log/puma-dev.log to see what the bootup errors are

Inspect your browser dev tools to see if there are any errors in loading the assets. It could be CORS policy blocking the assets.

This is usually something with the browser that is blocking the asset. It could be a browser extension or something.

The upgrade from 5.2.0 to 5.2.2 is fairly safe. There wasn't much changes. Have you looked at this episode yet https://www.driftingruby.com/episodes/upgrading-ruby-on-rails-versions?

Yes. You would upgrade the application locally and test everything to ensure that it is working properly. If you have a staging environment, it would then be best to test within there to make sure that you're not breaking functionality. This step is really important because we sometimes have services that are not "available" during development. For example, if you do file uploads to S3 in production, but in development, you use local disk, then all of your local development tests will not be touching the S3 APIs or code. This would be considered a risk when going to production, but a staging environment may catch any potential issues.
This is partly why I always try to mimic my production environment as closely as possible when developing. So in the previous example with S3 file uploads, I would use minio locally to mimic the S3 APIs for file uploads. It makes the development environment a bit more complicated, but would expose any potential breaking changes earlier on in the upgrade process.