siddharthd
3144cf3176
ci / lint-test (push) Successful in 58s
I1 refused any credits-funded order dated before 2026-01-09, storing
nothing at all — no transaction and no metadata, so the receipt was
discarded rather than kept as history.
Its reason was splits, not spend: before the cutover shared expenses
lived in SplitMyExpenses, and re-importing them would double-charge
against carryover transaction 2348. That reason expired with 788219b,
where ACTIVE_OBLIGATION became `settled = false AND transaction_date >=
'2026-01-09'`. A pre-cutover split can no longer assert a debt, so a
pre-cutover order cannot move a balance however it is recorded — and
ingestion writes no splits at any date, which now has a test of its own.
What the guard was still doing was hiding ordinary history: 275 orders,
$9,799.96 of meals and rides across 2020-2025, invisible only because the
money came from a gift-card balance instead of a card.
The funding side stays as it is, deliberately. Some of those orders were
paid from ShopBack gift cards that are themselves booked as expenses, so
that portion is counted twice. The exposure is bounded at $3,411.16 over
14 loads and is probably smaller: the descriptors name no brand — "ShopBack
Gift Cards SQ" is a batch code, and the card could be Amazon, Airbnb or
Shell as easily as DoorDash — and six are categorised `gifts`, which may
be real presents rather than self-funding. Reclassifying them on a guess
would corrupt correct data to fix a double-count that cannot be shown.
Only the ShopBack purchase emails can settle it, joined on total paid.
32 lines
1.8 KiB
SQL
32 lines
1.8 KiB
SQL
-- Let credits-funded orders exist before the cutover.
|
|
--
|
|
-- `chk_ingested_orders_after_cutover` (migration 0018) refused any row with
|
|
-- payment_method = 'credits' dated before 2026-01-09. It was written as a
|
|
-- database-level guard for invariant I1, whose stated reason was splits:
|
|
-- before the cutover, shared expenses lived in SplitMyExpenses, and
|
|
-- re-importing them would double-charge Sonu against carryover transaction
|
|
-- 2348.
|
|
--
|
|
-- That reason no longer holds. Since finance-app 788219b, ACTIVE_OBLIGATION is
|
|
-- `ts.settled = false AND t.transaction_date >= '2026-01-09'`, so a split on a
|
|
-- pre-cutover transaction cannot assert a debt at all. The guard now blocks
|
|
-- something it was never aimed at: the orders themselves, which are ordinary
|
|
-- historical spend. 275 of them — $9,799.96 of meals and rides across
|
|
-- 2020-2025 — were invisible because the receipt was the only record and the
|
|
-- money came from a gift-card balance rather than a card.
|
|
--
|
|
-- What is NOT resolved, and is accepted deliberately (user, 2026-07-28): some
|
|
-- of those orders were funded by ShopBack gift cards that are themselves
|
|
-- recorded as expenses, so that portion is counted twice. The exposure is
|
|
-- bounded at $3,411.16 (14 loads) and is probably smaller, because the
|
|
-- descriptors name no brand — "ShopBack Gift Cards SQ" is a batch code, and
|
|
-- the card could be Amazon, Airbnb or Shell as easily as DoorDash. Six are
|
|
-- categorised `gifts` and may be real presents rather than self-funding.
|
|
-- Reclassifying them on a guess would corrupt correct data to fix a
|
|
-- double-count that cannot be demonstrated, so they are left alone; only the
|
|
-- ShopBack purchase emails can settle it, joined on total paid.
|
|
--
|
|
-- The split guard is untouched: this changes what may exist, not what may be
|
|
-- owed.
|
|
ALTER TABLE transactions DROP CONSTRAINT IF EXISTS chk_ingested_orders_after_cutover;
|