Commit Graph

2 Commits

Author SHA1 Message Date
PrplHaz4
16d2bc0ce9 Don’t re-create pending SimpleFIN transactions when pending sync is disabled (#2835)
* fix(simplefin): skip pending entries in processor when pending is disabled

When SIMPLEFIN_INCLUDE_PENDING/syncs_include_pending is off, pending rows
already stored in raw_transactions_payload were still (re)created as
entries on every sync - including ones the user manually deleted - because
the setting only affected the API request, not reprocessing of the stored
payload.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* chore(simplefin): add rake task to prune stale pending rows from payload store

raw_transactions_payload accumulates transactions across syncs and is
never pruned, so pending rows fetched before pending inclusion was
disabled keep getting re-imported. This one-time maintenance task removes
them (dry-run by default; scope by item_id/account_id).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(simplefin): address PR #2835 review feedback on pending detection

Fix epoch-zero pending check treating non-numeric posted strings (e.g.
"unavailable") as pending via String#to_i coercion; compare against
explicit zero representations instead, matching posted_date. Dedupe the
prune_pending rake task's copy of this logic by delegating to a new
public SimplefinEntry::Processor.pending? class method. Also close a
test gap where SIMPLEFIN_INCLUDE_PENDING env var precedence over the
Setting wasn't actually exercised.

* test(simplefin): cover pending-guard precedence and add rake task tests

Add the missing mirror case for pending_enabled? precedence (env var
disabling pending over a permissive Setting) and add test coverage for
the prune_pending rake task, which previously had none: dry_run safety
default, correct pruning via the shared Processor.pending? predicate
(including the malformed-posted regression), and that it never touches
Entry/Transaction rows.

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-07-30 01:13:02 +02:00
Stephen Jolly
27aa222ed3 Stop backfill_encryption double-encoding json/jsonb columns (#2615)
* fix(backfill): stop backfill_encryption double-encoding json/jsonb columns

security:backfill_encryption's plaintext fallback reads jsonb columns via
read_attribute_before_type_cast, which returns the JSON text; assigning
that String to the encrypted setter encrypts the text itself, so the
column thereafter decrypts to a String instead of the original
Array/Hash. Parse the raw value for json/jsonb columns before handing it
to the encryptor. Adds a regression test that fails on main.

Fixes #2611

* fix(backfill): gate backfill on nil-ness so empty values get encrypted

Addresses the Codex review comment on #2615: empty values ({}, [], \"\")
are plaintext that needs encrypting, but the present? gates skipped them,
leaving data the encrypted getters raise on once keys are live. Several
payload columns default to {}. Also applies the same nil-gate to
backfill_sessions user_agent (same idiom; precautionary). Regression
test added.

* docs(security): scope note - backfill doesn't fix any existing double-encoding

Per review: rows corrupted by the pre-fix task decrypt successfully to a
String, so this task cannot distinguish them from legitimately stored
strings; auto-repair would risk mangling valid data for a bounded, shrinking
cohort. Document the limitation and point affected operators at the manual
recovery script in #2611. Also adopt column.type over sql_type substring
matching (review nitpick); behaviour unchanged.
2026-07-08 08:05:49 +02:00