Uh oh!
There was an error while loading. Please reload this page.
V184: remove the dead shop_currency setting - #785
Merged
Conversation
Nothing reads it — confirmed by a full grep over phoenix_kit, phoenix_kit_billing, phoenix_kit_ecommerce and a host application; the only occurrences were the V135 seed and this package's own ExpectedSchema manifest comment. A shop's actual default currency is the is_default=true row of phoenix_kit_currencies, resolved through PhoenixKitBilling.get_default_currency/0 — a second, unread "shop currency" setting is a trap for the next reader. V135 itself is not edited: its seed is ON CONFLICT DO NOTHING, so every already-migrated host already has the row and editing V135's text would change nothing for them while breaking chain_hash for everyone. down/1 restores the row with V135's exact seed statement, so a rollback never overwrites a value an operator re-created by hand after the deletion. This is a pure data migration — no table, column, index or constraint is touched — so expected_schema.ex is restamped over the 50 shipped files (dev_docs/squash/restamp_chain_hash.exs --restamp) rather than regenerated, the same mechanism used for V182. A full regenerate was attempted first and aborts in this environment on a pre-existing mode-shape mismatch between the stepwise and single-shot dumps of sync_shop_category_slugs()/ sync_shop_product_slugs() (identical definition text, different body_md5); it aborts identically on unmodified main, and those two functions are already deliberately excluded from this manifest since V171.
timujinne
commented
Sep 5, 2026
timujinne
left a comment
ContributorAuthor
There was a problem hiding this comment.
Independent review (read-only reviewer, separate from the author), range 5de7e6c6..7ad4ce56. Verdict: PASS, no findings against the V184 work.
Verified directly
down/1reproduces the V135 seed byte for byte (INSERT INTO … ("key","module","value","value_json") VALUES ('shop_currency','shop','USD',NULL) ON CONFLICT ("key") DO NOTHING);date_added/date_updated/uuidcarry DB defaults, so the omitted columns are correct in both the seed and the restore.up/1is theDELETEplus marker184;down/1restores and stamps183.expected_schema.exdiff is a@chain_hashrestamp plus a comment block;objects/1unchanged. V184 adds no table, column, index or constraint, so the restamp is the right mechanism (same as V182, commit 975f88f). The generator abort onsync_shop_*_slugsis reproduced on unmodifiedmainand those functions are already excluded from the manifest since V171.postgres.ex:@current_version 184, V184 entry marked latest, V183 entry kept.- Tests:
v184_test.exsruns the realup_statements/1/down_statements/1against a seeded row, including a hand-createdEURrow survivingdown.test/phoenix_kit/migrations/+ release_check test: 16 doctests, 448 tests, 0 failures.mix phoenix_kit.release_check: Migration Version Sync passes (V135..V184 contiguous, chain_hash matches 50 files); remaining items are feature-branch noise (CHANGELOG, branch, tag). - Commit by the author only; no version/CHANGELOG change.
Notes, not blockers
- On the host's stand branch (this PR merged with upstream main and PR #782's sitemap commits), the full suite shows one order-dependent failure in
admin_route_dedup_test.exs; it passes in isolation and its own moduledoc documents the parallel-compilation race. V184 touches onlylib/phoenix_kit/migrations/, no route or module-discovery code. mix testwithout a priorMIX_ENV=test mix compile --forcedid not compiletest/supportin this environment.
mdon added a commit
to mdon/phoenix_kit
that referenced
this pull request
Sep 6, 2026
…eir zone A stored instant does not say which regime wrote it. When `time_zone` moved from an integer offset to an IANA id (2.13.9) and five modules turned out to have added that value to other instants, the rows they had written could not be repaired: `phoenix_kit_settings.date_updated` holds the last change only, no settings writer logged to the activity feed, and the feed prunes after 90 days anyway. "What was this setting at that instant?" had no answer. `phoenix_kit_settings_history` records one row per settings write that changes a value — the value before and after, the actor when a person made it, a source, the time — and is never pruned. It is written at the query layer inside the same transaction as the write, so every public writer records (`update_setting`, the batch, the module and boolean forms, JSON settings, the admin pages) and a write that leaves the value as it was records nothing: saving the settings page does not produce a row per field. A restricted (secret) setting records that a change happened with both values withheld. The `actor_uuid` FK sets itself null when the account goes; the row stays. Every writer takes `actor_uuid:` and `source:`; the three admin settings pages pass the current user and `"settings"`. Reading it: `Settings.history/2` (newest first) and `Settings.value_at/2` — the newest change at or before the instant says what the value became; with none, the oldest change after it says what it was before recording began; with no history at all, the current value. The same migration adds `phoenix_kit_posts.time_zone` (varchar(64), nullable): the one core-owned table that stores a typed wall clock now carries the zone it was typed in, so the row can be re-resolved on its own (the posts module writes it). Rows written before hold nil. The manifest declares the thirteen objects by hand from a database the chain built; `chain_hash` restamped over 50 files; the four-file manifest gate and the full suite with integration are green (one order-dependent media-page flake passes alone, with and without this change). Migration V184 collides with the open draft BeamLabEU#785's V184 — whichever merges second renumbers, per AGENTS.md. Not here: an admin view of the history, and the user's own timezone — the activity feed already records `user_timezone_from`/`_to` on a profile change, and the module rows carry their zone from now on.
timujinne
marked this pull request as ready for review
September 6, 2026 00:34
mdon added a commit
to mdon/phoenix_kit
that referenced
this pull request
Sep 6, 2026
Upstream's BeamLabEU#785 took V184 (the dead shop_currency setting removed), so this branch's activities/posts migration moves to V185: file, module, marker, moduledoc entry, the manifest's three declarations and header note; chain hash restamped over the 51 shipped files; the chain re-run into a fresh database (V135→V185) and the full suite green.
ddon added a commit
that referenced
this pull request
Sep 6, 2026
V185: currency-freeze columns on carts, cart items and orders (stacked on #785)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
V184: remove the dead
shop_currencysettingOne new chain version.
V135seeds ashop_currencysetting (INSERT … ON CONFLICT ("key") DO NOTHING, valueUSD, moduleshop). Nothing reads it: a full grep overphoenix_kit,phoenix_kit_billing,phoenix_kit_ecommerceand a host application finds only the V135 seed and theExpectedSchemamanifest. The default currency is theis_defaultrow ofphoenix_kit_currenciesand nothing else; a second "shop currency" that does nothing is a trap for the next reader (a host had two disagreeing "defaults" side by side for months without noticing).Why a new version and not an edit of V135
vNNN.exchangeschain_hash/0and failsrelease_checkfor every host.ON CONFLICT DO NOTHING, so every already-migrated install keeps its row. Only aDELETEin a new version reaches them.What V184 does
up:DELETE FROM phoenix_kit_settings WHERE "key" = 'shop_currency', marker184.down: re-inserts the row with the V135 seed statement verbatim (ON CONFLICT DO NOTHING, so a row a host re-created by hand is never overwritten), marker183.postgres.ex@current_version 184, moduledoc entry;expected_schema.exregenerated withdev_docs/squash/generate_baseline.exs(not hand-edited).test/phoenix_kit/migrations/v184_test.exs: up removes the row and stamps 184; down restoresUSDand stamps 183; down leaves a hand-createdEURrow untouched.Companion PRs in the same work (per-domain currency, stage Э0): BeamLabEU/phoenix_kit_billing#30, BeamLabEU/phoenix_kit_ecommerce#31.
Manifest and tests
expected_schema.exis restamped withdev_docs/squash/restamp_chain_hash.exs --restamp— the documented path for a version that adds, drops or reshapes nothing (precedent: V182, commit 975f88f). A full regeneration was attempted first and the generator aborts on this environment at the mode-shape diff forsync_shop_category_slugs()/sync_shop_product_slugs()(identical definitions, differentbody_md5between the stepwise and single-shot schemas); it aborts identically on unmodifiedmain. Those two trigger functions are deliberately not declared in the manifest since V171 (comment near line 27778), but the generator's guard runs before that exclusion applies. Left as a tooling note, not fixed here.phoenix_kit_release_check_test.exs).test/phoenix_kit/migrations/: 433 tests + 16 doctests, 0 failures,v184_test.exsincluded.check_migration_sync/0: V135..V184 contiguous, every module loadable.mix testin this checkout did not compiletest/support(7 files) on its own;MIX_ENV=test mix compile --forcefollowed bymix test --no-compilewas used.Host verification
Applied on a live host through
phoenix_kit_update_v182_to_v184(V183 + V184):shop_currencyrow gone, marker184, storefront 200 on both domains, no errors in the log after restart.Not in this PR
Version bump and CHANGELOG (maintainer). The next stage adds V185 (currency freeze columns on carts/orders).