Remove unused unsubscribed column from members
Maintainer antworten meist innerhalb von 1 Tag
@mroderick arbeitet bereits daran.
Seit 12.10.2026.
Bewertung
Dieses Issue wurde noch nicht bewertet.
Beschreibung
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.
- Vorherrschende Sprache
- Ruby
- Sterne
- 105
- Forks
- 206
- Ø Merge
- 19 Std. 31 Min.
- Gemergte PRs (30 T.)
- 84
Entwicklungsumgebung
- Enthält ein Dockerfile oder eine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus codebar/planner
-
DashboardQuery eager-loads workshop_host with :sponsors in one join (same host-loss trap as #2975)Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 1 Tag
-
Dual Invitiation issueEvtl. vergeben @mroderick hat das vor 1 Tag übernommen. Offen
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 42/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 28/100
codebar/planner#3008 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in codebar/planner
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
:bank: debt
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
cucumber/cucumber-ruby-core#346 · 1 Kommentar ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 75/100
TheOdinProject/curriculum#31467 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
message-patterns
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
sisimai/rb-sisimai#468 ·