Troubleshooting

Gotchas

• Difference between buildtime environment variables and runtime environment variables in the Docker containers and the static props.
  • Example:
    • The production site had nothing in the database as shown by using https://backend-core-tj3gg4i5eq-uc.a.run.app/docs/ to execute a few queries.
    • The deployed partners and public sites were able to login and display applications and listings management, how?
    • Answer: when the images were being built, the env variable BACKEND_API_BASE was undefined in GCP, so it used the default value of localhost:3100 to build all the links and get the static props. Then, when I clicked login, the production site talked to the dev instance of backend/core running on my local machine! Very unexpected.
• Navbar: we've hardcoded the width of li.progress-nav__item to be 20% the width of the full navbar (https://github.com/CityOfDetroit/bloom/pull/620), since the only instance of the navbar has five sections. If we add another section or create another page that uses the navbar, we'll need to change that styling.

General

• Permission denied on one of the build folders (backend/core/dist/, node_modules/, sites/partners/.next/, sites/partners/node_modules/).
  • This seems to happen due to the containers running as the root user in the container and the directories are mounted from the containers to prevent copying/overwriting the container's internal directories with the external directory. The docker-compose does not seem to work without those lines and if we remove all the directory mounts then we wouldn't get edit/refresh.
  • One idea for fixing this is to CHOWN the /usr/src/app directory and then switch to a different user inside the container, but if we used a generic user like node:node for permissions, I don't think that would still give your local user permission to edit those directories.
  • The workaround is easy - just sudo rm those directories, or sudo yarn clean.
• TCP:5432 is already taken up by a postgres instance when starting docker-compose.
  • Try stopping any services you have running locally before starting them in containers:

    sudo service redis-server stop
    sudo service postgresql stop
    # for mac:
    brew services stop redis-server
    brew services stop postgresql
  

• Local site takes forever to become available
  • Depending on your machine, if you're starting a dev build locally, sometimes it can take a really long time (O(minutes)) for the /listings endpoint to become available. If you're having this problem, trying starting just the public or partner portal instead of both portals.
  • We think this is because of complex table joins, but more investigation is required.

Deployment

• backend/core fails to deploy with Please run yarn db:migration:run before starting the app.
  • Ensure that your postgres service or container is stopped. Then run the run_prod_database_migration.sh script from the bin/ directory.