mirror of
https://github.com/we-promise/sure.git
synced 2026-08-05 08:32:15 +00:00
9313ad4cba
* fix: tolerate Enable Banking pagination/PDNG errors for Trade Republic Trade Republic (available via Enable Banking since ~2026-07-22, see #392) fails to sync with two distinct errors on its own side: 1. The BOOK transaction fetch issues a continuation_key on page 1 that its own API then rejects on page 2 as mismatched with transaction_status (422 WRONG_REQUEST_PARAMETERS: "transactionStatus in request is not the same as in continuationKey"). This previously discarded every page already fetched. Once at least one page has succeeded, a validation error is now treated as pagination exhausted and the partial result is kept instead of raising. A validation error on the very first page still propagates as a real failure. 2. The PDNG (pending) fetch is rejected with a plain 400 (:bad_request) instead of the 422 (:validation_error) other ASPSPs use for the same "transaction status not supported" case. Both error types are now treated as "ASPSP doesn't support pending transactions". Verified against a live Trade Republic connection through Enable Banking. * fix: surface Enable Banking pagination truncation as a debug log entry Add a DebugLogEntry.capture call when a mid-pagination validation error truncates the transaction fetch (e.g. the Trade Republic continuation_key bug from the previous commit). This follows the project convention of using DebugLogEntry for support-relevant sync diagnostics rather than only Rails.logger, so a truncated sync is visible in /settings/debug instead of only in container logs. Currently harmless for narrow incremental sync windows (the account observed in production has under 100 transactions per window, fitting entirely on page 1), but a wider historical resync could otherwise lose data past page 1 with no visible indication. * fix: address CodeRabbit review feedback on PR #2828 - Add a DebugLogEntry when the PDNG fetch is skipped as unsupported, matching the pattern already used for pagination truncation — this was a partial-degradation case that was previously only visible via Rails.logger. - Replace the OpenStruct#define_singleton_method provider fakes in the three new pagination tests with sequenced Mocha stubs (expects(...).twice.returns(...).then.raises(...)), per the project's "use Mocha for stubs and mocks" guideline. * fix: don't swallow WRONG_TRANSACTIONS_PERIOD as pagination truncation The mid-pagination validation-error handling treated any 422 after page one as "ASPSP rejected the continuation key" and kept the partial result as a success. WRONG_TRANSACTIONS_PERIOD is a different, real failure (an invalid date range, already retried once with a corrected date_from at the provider level) and must still propagate instead of silently dropping the remaining pages. Addresses CodeRabbit review feedback on PR #2828. * fix: address jjmata's review feedback on partial-result asymmetry - fetch_paginated_transactions now tolerates :bad_request the same way it already tolerates :validation_error mid-pagination, matching the PDNG-unsupported rescue in fetch_and_store_transactions which already accepts both error types. Without this, a :bad_request on PDNG page 2+ would discard the already-fetched PDNG page 1 instead of keeping it like the BOOK path does. Trade Republic only 400s on PDNG page 1 today, so this was latent, not currently observed. - Bump the pagination-truncation log (Rails.logger + DebugLogEntry) from warn to error: this now discards data for any ASPSP/scenario matching the tolerated error types mid-pagination, not just the specific Trade Republic case it was written for, so it deserves higher visibility. - Add a regression test for :bad_request interrupting PDNG pagination on page 2+, pinning down the now-symmetric behavior with BOOK.