From 5ceb3ec42e4c954451678ea9249cfdfd0e7d5154 Mon Sep 17 00:00:00 2001 From: "david.delagneau" Date: Thu, 30 Apr 2026 11:28:14 -0600 Subject: [PATCH] docs: update Discourse AccountLink investigation status and capture April 30 daily progress --- project-knowledge/01-current/current-work.md | 9 +++++--- project-knowledge/06-daily/2026-04-29.md | 24 ++++++++++++-------- project-knowledge/06-daily/2026-04-30.md | 5 ++++ 3 files changed, 26 insertions(+), 12 deletions(-) create mode 100644 project-knowledge/06-daily/2026-04-30.md diff --git a/project-knowledge/01-current/current-work.md b/project-knowledge/01-current/current-work.md index d3cc918..887ab12 100644 --- a/project-knowledge/01-current/current-work.md +++ b/project-knowledge/01-current/current-work.md @@ -2,7 +2,7 @@ type: current project: fidelity status: active -updated: 2026-04-29 +updated: 2026-04-30 tags: - current-work - fidelity @@ -46,8 +46,10 @@ tags: - Do not merge the GraphQL/Apollo removal PR until the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for 30 days without issues - Current `PDIAP-15838` follow-up centers on the `PicoSDK` update in `SampleApp`: the newer Pico path removes the remaining transitive Apollo dependency, re-enables FGO and FidFolios testing in `SampleApp`, and aligns the sample implementation with current Fid4 usage - The `PicoSDK` update affects `SampleApp`, not the `XFlowSDK` production runtime directly -- The new Discourse / FTTransfer AccountLink issue is under investigation; Zachary believes it may come from XFlow, but ownership should not be stated until David reproduces it and confirms scope -- For the Discourse / FTTransfer issue, David has `FTTransferPlayground` running near Zachary's reported path but is currently blocked before the web view by phone-number verification / a Face ID-related error +- The new Discourse / FTTransfer AccountLink issue is under investigation; Zachary believes it may come from XFlow, but current evidence shows it reproduces in `FTTransferPlayground` with Zachary's account and does not reproduce in `Fid4` with the same account +- Current Discourse / FTTransfer findings point to the `BankInformationView` path rather than XFlow directly: XFlow appears to finish before `BankInformationView` takes over, and the web-view reload looks like a SwiftUI recomposition/state issue in the playground path +- Continue the Discourse / FTTransfer investigation to verify root cause and any remaining relationship to XFlowViewMaker before assigning ownership or creating a story +- Jeff asked David to try to resolve the Discourse consumer issue by end of day on April 30 if possible - Before closing out the AO thread, send one more working-group Teams reply that summarizes the original iOS issue, links the Jira comment, Discourse comment, and PR, and separates the remaining `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue - The `HybridBrokerageAccountOpening` / `JointIdentityCheck` rule-content issue appears unchanged between QA and Production in Cogstore and should be treated as the remaining service-side follow-up @@ -87,6 +89,7 @@ tags: - When one Jira item has multiple concrete updates, prefer one top-level Jira bullet with indented sub-bullets rather than repeating the same Jira line multiple times - When pairing a Jira ID with a title in standups, prefer a simple hyphen after the ID or omit punctuation instead of using commas - For Friday standups that may also be sent to Teams, prefer plain language over internal implementation terms; avoid words like `fallback` unless the meaning is obvious to the audience +- For standups that may also be sent to Teams, keep the update concise, omit internal review-feedback details, and avoid phrasing like `confirmed` when the audience lacks the internal context for what was confirmed - When a release item is waiting on approvals or pipeline work, make the parallel story work explicit instead of making the update sound blocked on waiting alone - Standups should omit side questions or manager-only context refreshes unless they materially changed story work - For `PDIAP-15838` standups, focus on Apollo-removal progress and the `PicoSDK` transitive dependency work; omit extra exploratory asks unless they directly changed the story outcome or created a blocker diff --git a/project-knowledge/06-daily/2026-04-29.md b/project-knowledge/06-daily/2026-04-29.md index acbd970..85ebdf9 100644 --- a/project-knowledge/06-daily/2026-04-29.md +++ b/project-knowledge/06-daily/2026-04-29.md @@ -5,11 +5,11 @@ date: 2026-04-29 status: active focus: [ao-discourse] work-items: [] -blockers: [phone-verification-gate-in-fttransferplayground] +blockers: [] tags: - daily - fidelity -updated: 2026-04-29 +updated: 2026-04-30 --- # 2026-04-29 @@ -25,31 +25,37 @@ updated: 2026-04-29 - David successfully configured the `FTTransferPlayground` environment. - For the version Zachary mentioned, David did not find a matching branch; the closest match found was the tag `Release/Foundation/5.0.0-beta.24`, assumed to correspond to the `5.0.24 beta` version Zachary referenced. - David reached the flow so it now looks similar to Zachary's video, but the app asks for phone-number verification before the web view loads. +- David asked Zachary for reproduction details, including whether the issue reproduces in `Fid4` and which account/steps were used. +- With the account Zachary shared, David reproduced the issue in `FTTransferPlayground`. +- David tested the same account in `Fid4`, but the issue did not reproduce there. +- David narrowed the visible issue to the `BankInformationView` path rather than XFlow directly: an XFlow flow occurs before the web view is presented, but it finishes before `BankInformationView` takes over. --- ## Findings -- David does not yet know how to bypass the phone-number verification step in `FTTransferPlayground`. -- In prior `Fid4` validation, a similar step could be bypassed by enabling Face ID, but trying that in `FTTransferPlayground` produced a separate error that is not yet understood. -- The current follow-up may require asking Zachary which user he used or whether he knows what causes the Face ID / verification error in this app. +- The issue occurs when tapping `exit`: the alert appears, but the view immediately rebuilds. +- The behavior currently looks like a SwiftUI recomposition issue: `.state` is updated to `.loading`, which triggers a redraw, presents an `EmptyView`, dismisses the alert, and reloads the web view. +- The remaining uncertainty is why this happens in `FTTransferPlayground` but not in `Fid4`. --- ## Communication - David updated Jeff with the `FTTransferPlayground` setup status and the current verification blocker. +- Jeff asked David to ping Zachary directly for help, including asking whether Zachary has seen the issue in `Fid4` and how David might reproduce it there. +- David reported that the issue reproduces in `FTTransferPlayground` with Zachary's account but not in `Fid4` with the same account. +- Jeff asked David to prioritize resolving the Discourse consumer issue by end of day on April 30 if possible. --- ## Next Steps -- Keep trying to reproduce the FTTransfer / AccountLink issue through `FTTransferPlayground`. -- Determine whether the phone-verification step can be bypassed locally. -- If not, ask Zachary which user/account he used or whether he knows why the Face ID path errors in this app. +- Continue deeper testing to isolate why the behavior occurs in `FTTransferPlayground` but not in `Fid4`. +- Verify the root cause and whether there is any remaining relationship to XFlowViewMaker before assigning ownership or creating a story. --- ## Blockers -- Phone-number verification currently blocks reaching the web-view portion of the flow in `FTTransferPlayground`. +- None currently. diff --git a/project-knowledge/06-daily/2026-04-30.md b/project-knowledge/06-daily/2026-04-30.md new file mode 100644 index 0000000..620ca87 --- /dev/null +++ b/project-knowledge/06-daily/2026-04-30.md @@ -0,0 +1,5 @@ +# 2026-04-30 + +## Context Updates +- Jeff requested confirmation on whether the webview reload issue is tied to `XFlow`. If not, we need to compare the failing flow against Zachary's working non-XFlow entry point to understand the discrepancy. +- David reported that the issue seems isolated to a premature deallocation in the SwiftUI lifecycle between `BankInformationView` and `BankSetupWebView`, meaning it does not appear to be an `XFlowViewMaker` bug.