docs(ibkr): use Last 365 Days (no 'Last 90 Days' preset in IBKR UI)
Some checks are pending
CI / test (push) Waiting to run
CI / build (push) Blocked by required conditions
CI / deploy (push) Blocked by required conditions
ci/woodpecker/push/build Pipeline was successful

This commit is contained in:
Viktor Barzin 2026-05-27 09:28:42 +00:00
parent ceb652b623
commit bb9e0d4567
3 changed files with 5 additions and 5 deletions

View file

@ -1461,7 +1461,7 @@ OpenPositions against WF-computed quantities.
| Open Positions | symbol, position, markPrice, currency, assetCategory | | Open Positions | symbol, position, markPrice, currency, assetCategory |
| Securities Information | symbol, description, conid | | Securities Information | symbol, description, conid |
Date range: `Last 90 Days` — trailing window so a missed cron run Date range: `Last 365 Days` — trailing window so a missed cron run
doesn't lose data. SyncRecordStore makes overlapping pulls idempotent. doesn't lose data. SyncRecordStore makes overlapping pulls idempotent.
Switch to `Year to Date` or `Custom Date Range` only for one-time Switch to `Year to Date` or `Custom Date Range` only for one-time
historical backfills. historical backfills.

View file

@ -39,7 +39,7 @@ a new query named `broker-sync-activity` with:
**Date Format:** `yyyy-MM-dd`. **Time Format:** `HH:mm:ss` (no timezone **Date Format:** `yyyy-MM-dd`. **Time Format:** `HH:mm:ss` (no timezone
suffix — ibflex 1.1 rejects timezone abbreviations in the time field). suffix — ibflex 1.1 rejects timezone abbreviations in the time field).
**Date Range:** `Last 90 Days` — trailing window so a missed cron run **Date Range:** `Last 365 Days` — trailing window so a missed cron run
doesn't lose data. SyncRecordStore (keyed by `external_id`) makes doesn't lose data. SyncRecordStore (keyed by `external_id`) makes
overlapping pulls idempotent. For a one-off historical backfill, widen overlapping pulls idempotent. For a one-off historical backfill, widen
temporarily to `Year to Date` or `Custom Date Range`, run once, then temporarily to `Year to Date` or `Custom Date Range`, run once, then

View file

@ -210,7 +210,7 @@ top.
- Sections: `Account Information`, `Trades`, `Cash Transactions`, - Sections: `Account Information`, `Trades`, `Cash Transactions`,
`Open Positions`, `Securities Information` `Open Positions`, `Securities Information`
- Date Format: `yyyy-MM-dd` · Time Format: `HH:mm:ss TimeZone` - Date Format: `yyyy-MM-dd` · Time Format: `HH:mm:ss TimeZone`
- Date Range: `Last 90 Days` — trailing window so a missed cron run - Date Range: `Last 365 Days` — trailing window so a missed cron run
(failed pod, outage, vacation) doesn't lose data. SyncRecordStore (failed pod, outage, vacation) doesn't lose data. SyncRecordStore
keys on `ibkr:trade:<tradeID>` / `ibkr:cash:<transactionID>`, so keys on `ibkr:trade:<tradeID>` / `ibkr:cash:<transactionID>`, so
overlapping pulls are no-ops. `Last Business Day` was the original overlapping pulls are no-ops. `Last Business Day` was the original
@ -252,11 +252,11 @@ curl -sS -b /tmp/wf-jar -X POST "$WF_BASE_URL/api/v1/accounts" \
### Step 4 — Initial backfill (skip while account is empty) ### Step 4 — Initial backfill (skip while account is empty)
When the IBKR account first holds positions, the daily CronJob will When the IBKR account first holds positions, the daily CronJob will
backfill automatically up to the 90-day trailing window. For older backfill automatically up to the 365-day trailing window. For older
history, temporarily switch the Flex query Date Range to history, temporarily switch the Flex query Date Range to
`Year to Date` (or `Custom Date Range` with a 1-year window), run the `Year to Date` (or `Custom Date Range` with a 1-year window), run the
CronJob manually once, verify WF totals match the broker app, then CronJob manually once, verify WF totals match the broker app, then
switch the Flex query back to `Last 90 Days` for daily incremental. switch the Flex query back to `Last 365 Days` for daily incremental.
Dedup makes the temporary widening safe — already-synced rows are no-ops. Dedup makes the temporary widening safe — already-synced rows are no-ops.
### Step 5 — Deploy ### Step 5 — Deploy