Til Tracker

`rails db:seed` failed (NameError due to heredoc interpolation)

Context: I ran the generated seed script which populated Learning records from LEARNINGS.md. The error occurred processing an entry whose body contained the literal text params[:tag]. The default heredoc syntax (<<~BODY) attempted Ruby interpolation (#{...}) on this text, causing NameError: undefined local variable or method 'params' for main:Object.
Resolution: I changed the heredoc definition for the problematic entry in db/seeds.rb from <<~BODY to <<~'BODY' (note the single quotes). This prevents interpolation within that specific string, treating it literally.
Learning: I learned to be cautious when using interpolating heredocs (<<~DELIMITER) in seed files or scripts if the source text might contain #{}, ${}, or similar sequences that could be misinterpreted as code interpolation. Use non-interpolating heredocs (<<~'DELIMITER') or escape the relevant characters (\#{}) within the string if interpolation is needed elsewhere but not for specific literals.

Tags: seeds database ruby heredoc interpolation error debugging workflow

Learned on: April 20, 2024 Edit

Render: Running initial migrations on free tier (Build Command workaround)

Context: I needed to run initial database migrations (rails db:migrate) on Render's free tier, which lacks Shell access or explicit Pre-Deploy/Post-Deploy command support. Migrations must run after the code is deployed and dependencies installed but before the server starts taking requests based on the new schema.
Resolution (Workaround): I temporarily added bundle exec rails db:migrate to the *end* of the Build Command in Render settings for the first successful deployment (e.g., bundle install; bundle exec rails assets:precompile; bundle exec rails db:migrate).
Learning: On restricted environments (like PaaS free tiers), essential post-deploy tasks like database migrations might need temporary workarounds, such as including them at the end of the build command. I learned to remember to remove the migration step from the build command after the first successful run to avoid unnecessary migrations on subsequent deploys and potentially slow down builds. Considering using release phase tasks if the platform supports them (Render paid tiers do) is a good idea for the future.

Tags: deployment-ci database migration workflow

Learned on: April 14, 2024 Edit

Render: Continued socket errors (Missing `DATABASE_URL`)

Context: I continued to see socket connection errors even with the production environment confirmed. The DATABASE_URL environment variable itself was missing from the Web Service configuration.
Cause: The Render PostgreSQL database service was not automatically linked to the Web Service when I created it, or the link was broken/not established. Render doesn't always automatically inject the DATABASE_URL from a linked DB into the web service environment.
Resolution: I manually located the database 'Internal Connection String' from the database service's page in Render and added it as the DATABASE_URL environment variable to the Web Service settings.
Learning: I learned to verify that the DATABASE_URL environment variable exists and is correctly populated in the deployment environment. If using linked services (like Render databases), I need to ensure the link is active and injecting the variable, or manually provide the connection string if necessary.

Tags: deployment-ci database environment-setup

Learned on: April 14, 2024 Edit

Render runtime errors (`ActiveRecord::ConnectionNotEstablished` - Socket)

Context: I encountered runtime errors (ActiveRecord::ConnectionNotEstablished) trying to connect via local socket (/var/run/postgresql/.s.PGSQL.5432). Despite config/database.yml being configured for DATABASE_URL, Rails was not running in the production environment, causing it to default to socket connections defined elsewhere in database.yml (likely development).
Cause 1: The Start Command initially included -e ${RACK_ENV:-development} or similar, overriding the production setting.
Cause 2: The RAILS_ENV environment variable was missing or incorrect in Render.
Cause 3: Puma reported Environment: development or deployment even with RAILS_ENV=production set, suggesting RACK_ENV might take precedence or another override was present.
Resolution:
* I changed the Start Command to bundle exec puma -C config/puma.rb (removing explicit -e).
* I explicitly added both RAILS_ENV=production and RACK_ENV=production environment variables in Render's UI.
Learning: I learned to ensure the Rails environment is correctly set to production on the deployment server via RAILS_ENV (primary) and potentially RACK_ENV environment variables. I need to verify the environment Puma/Rails reports in the logs and check the Start Command for overrides.

Tags: deployment-ci database environment-setup

Learned on: April 14, 2024 Edit

Render build failures (`DatabaseNotDefined`)

Context: My builds failed related to database configuration (ActiveRecord::DatabaseConfigurations::DatabaseNotDefined: Database configuration "'default'" not defined). The default config/database.yml included a complex multi-database production setup that was incompatible with Render's standard DATABASE_URL environment variable approach.
Resolution: I simplified the production: block in config/database.yml to inherit defaults and rely solely on the DATABASE_URL environment variable provided by Render (e.g., `production:
<<: *default
url: <%= ENV['DATABASE_URL'] %>). Rails 7+ often handles DATABASE_URL` automatically if the production block is simple enough or just inherits defaults.
Learning: For standard PaaS deployments (like Render, Heroku), I learned to configure the production database section in config/database.yml to use the DATABASE_URL environment variable provided by the host. Avoid complex hardcoded setups unless explicitly needed and configured on the host. Rely on Rails conventions.

Tags: deployment-ci database environment-setup

Learned on: April 14, 2024 Edit

NoMethodError: undefined method `learned_on` on `new` learning page

Context: The new.html.erb view tried to access @learning.learned_on to set the default value for the date field (value: @learning.learned_on || Date.today), causing NoMethodError.
Resolution: I changed the date_field value in the view to just value: Date.today. The @learning instance created by LearningsController#new (Learning.new) is unsaved and doesn't have attributes populated from database defaults until saved.
Learning: I learned to be mindful of when database defaults are applied (on save) versus needing to set defaults explicitly in the controller (Model.new(attr: default)) or view (value: default) for new object instances presented in forms.

Tags: rails-core controller view form model date nomethoderror database default

Learned on: April 13, 2024 Edit

Feature: Implemented retroactive learning logging

Feature: I implemented retroactive learning logging.
Details: I added learned_on date field (type: :date, null: false, default: 'CURRENT_DATE') to the Learning model/migration. I updated the controller learning_params to permit :learned_on. I updated index sorting to use ORDER BY learned_on DESC, created_at DESC. I added a date_field to _form.html.erb. I updated index view display.
Learning: I learned that using SQL default CURRENT_DATE is effective for database-level defaults upon record creation. However, for new, unsaved records in a form, a default needs to be set in the view (e.g., <%= form.date_field :learned_on, value: Date.today %>) or controller (@learning = Learning.new(learned_on: Date.today)).

Tags: feature rails-core model migration controller view form database sql date

Learned on: April 13, 2024 Edit

`rbenv exec rails db:create` failed (`ActiveRecord::ConnectionNotEstablished`)

Context: rbenv exec rails db:create failed with ActiveRecord::ConnectionNotEstablished. The PostgreSQL server was not running or accessible.
Resolution: I started the PostgreSQL service (e.g., brew services start postgresql).
Learning: I learned to ensure required background services like databases are running before Rails attempts to connect to them (e.g., rails db:create, rails server). Checking service status (brew services list) is important.

Tags: database environment-setup rails-core

Learned on: April 09, 2024 Edit

`rbenv exec bundle install` failed (`pg` gem build header not found)

Context: rbenv exec bundle install failed again on pg gem build (Can't find the 'libpq-fe.h' header). Although I had installed libpq via Homebrew, the build process (even when run via rbenv exec) didn't know where to find the necessary header files and libraries.
Resolution: I explicitly configured Bundler to tell the pg gem build process where to find the Homebrew libpq installation using rbenv exec bundle config build.pg --with-pg-config=/opt/homebrew/opt/libpq/bin/pg_config, followed by rbenv exec bundle install.
Learning: For gems with native extensions that depend on external libraries installed in non-standard locations (like Homebrew on Apple Silicon), I learned I may need to provide explicit configuration hints to the build process using bundle config build.<gem_name> --with-<config-option>=/path/to/dependency. Checking brew info libpq for paths is useful.

Tags: environment-setup database

Learned on: April 09, 2024 Edit

`rails new` failed on `bundle install` (pg gem native extension build)

Context: rails new failed during initial bundle install with ERROR: Failed to build gem native extension. for the pg gem. The pg gem requires the PostgreSQL client library (libpq) to build its native C extension.
Resolution: I installed the client library using brew install libpq.
Learning: Native extensions for gems often depend on external system libraries. I learned to read the error messages carefully, as they usually suggest the required package and installation command (e.g., brew install libpq).

Tags: environment-setup database

Learned on: April 09, 2024 Edit

`brew services start postgresql` failed (formula not installed)

Context: I tried to start the database service required by the Rails app using brew services start postgresql. It failed with Formula 'postgresql@14' is not installed.
Resolution: I installed PostgreSQL using brew install postgresql, then started the specific versioned service with brew services start postgresql@14.
Learning: I learned to ensure required background services (like databases) are installed via the package manager (Homebrew) before attempting to start them. I also need to verify the correct formula name if using versioned formulas (e.g., postgresql@14 vs postgresql).

Tags: database environment-setup

Learned on: April 09, 2024 Edit