Remove unused unsubscribed column from members
Los mantenedores suelen responder en 1 día
@mroderick ya está trabajando en esto.
Desde el 12/10/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
Problem
The members.unsubscribed boolean column is dead and should be dropped. Nothing reads or writes it. It survives in db/schema.rb and in production data only.
Git history shows when it died:
- 2013-10-21 (
86bae547): migration20131021040356_add_unsubscribed_to_member.rbadded the nullable boolean,MembersController#unsubscribeset it totrue, and the invitation email carried the unsubscribe link. - 2014-03-29 (
bd0772a2):default_scope -> { where(unsubscribed: [false, nil]) }became the only read. - 2014-06-22 (
59df6c1c): that default scope was removed. Nothing has read the column since. - 2014-08-24 (
0cdd988a): theunsubscribeaction became a signed-token redirect to the subscriptions page. The write went with it. Nothing has written the column since.
Unsubscribing today runs through soft-deleted subscriptions (Discard, tombstones per #2920); the newsletter opt-in is tracked in opt_in_newsletter_at. The originating migration was deleted with the pre-2026 migration purge (fd7e972f).
Production data
The column still holds the 2013-2014 clicks (snapshot 2026-10-12): 84 true, 6 false, 29,576 NULL. All 90 non-null values belong to members created between 2013-10-21 and 2014-07-01. Of the 84 flagged members, 11 hold active subscriptions today and have received mail for years regardless of the flag, and 2 have opted into the newsletter since.
Recommendation: drop the column without changing any subscription state. The flag has been inert for over 12 years; acting on it now would apply decade-old intent over current state, including over the 2 later opt-ins. The counts above are the last trace of the feature.
Why the two-step removal is load-bearing
Production runs with Heroku preboot: the release phase runs migrations before new dynos boot, and old dynos keep serving against the new schema during the switch. Old releases build their member SELECT list from their schema cache and name every column explicitly (SELECT "members"."id", ..., "members"."unsubscribed", ...). Dropping the column while old dynos serve would fail every member query on them with PG::UndefinedColumn. Writes are not affected: partial_inserts keeps the nullable, default-less column out of INSERTs.
So the removal stays as proposed:
- Add
unsubscribedtoself.ignored_columnsonMemberand deploy. The column then drops out of the new release's SELECT list and out of the model's attribute methods. - In a separate deploy, wrap
remove_column :members, :unsubscribedinsafety_assured. strong_migrations 2.8 prescribes exactly this sequence.
Verification notes
- grep and ast-grep across
app,lib,config,spec,db: no code reference to the column. Matches are comments, locale strings, view prose and spec variable names only. - No migration in
db/migrate/references it. The originating migration was deleted infd7e972f. - No database views or triggers reference the column.
- The codebar auth app does not reference the column.
Member.all.to_sqlon master namesmembers.unsubscribedin the SELECT list; withignored_columnsset it does not.
- Lenguaje dominante
- Ruby
- Estrellas
- 105
- Forks
- 206
- Merge medio
- 19 h 31 min
- PR fusionados (30 d)
- 84
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de codebar/planner
-
DashboardQuery eager-loads workshop_host with :sponsors in one join (same host-loss trap as #2975)Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dual Invitiation issuePosiblemente ocupada @mroderick la tomó hace 2 días. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 42/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 28/100
codebar/planner#3008 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de codebar/planner
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
thewca/worldcubeassociation.org#16088 ·
Los mantenedores suelen responder en 1 día
-
cocoapods: bundled activesupport raises `unknown keyword: quirks_mode` once json 3 is installedAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Homebrew/homebrew-core#319232 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
enhancement help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
ecosyste-ms/repos#1215 ·
Los mantenedores suelen responder en 1 día