david.delagneau
1ad707373a
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
3.3 KiB
3.3 KiB
type, project, date, status, focus, work-items, blockers, tags, updated
| type | project | date | status | focus | work-items | blockers | tags | updated | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| daily | fidelity | 2026-05-18 | active |
|
|
|
2026-05-18 |
2026-05-18
Work Done
- Sent the daily scrum update for
PDIAP-12284 - Remove UIKit wrapping from XFlow: continued SampleApp validation in both host modes, aligned the host-mode path with current flag behavior instead of the deprecatedenable-swift-uitoggle, and started broader Fid4 smoke testing with temporary validation logs.
Findings
- While refreshing context for Adam's duplicate-request question, David clarified that the April 4 follow-up in the
Production - Crypto Delinking issuethread was from David/Jeff's side after Yuva's March 30 comment. - That April 4 follow-up said the iOS SDK-side network requests looked correct and intentional, matched Android, and did not reproduce duplicate
open-accountAPI calls from the client side in non-prod. - Therefore, prior
PDSPS-29371context should not be summarized as a confirmed reproduction from the iOS SDK side; it is related background, but the previous investigation did not reproduce the issue from the client-side SDK path. - Follow-up Copilot analysis suggested a plausible but unconfirmed link between REST migration and the current duplicate-page/account report: REST did not introduce a new duplicate-trigger mechanism by itself, but the REST/FTNetwork path may have changed timeout/error behavior enough to expose an existing XFlow re-trigger path under slow BPDC responses.
- Treat that REST link as a hypothesis requiring current logs, dates, versions, and timeout/error evidence before reporting it as root cause.
- Jeff asked whether the REST switch could have impacted Adam's duplicate-page/account report, while noting he assumed they were unrelated. David initially answered that REST should only affect XFlow API transport, not page sequencing or submission count, and offered to trace REST-toggle state once Adam provided an exact date and flow/page.
- After Adam provided more context, David updated Jeff that REST still should not be treated as a direct sequencing cause, but it cannot be fully ruled out because REST/FTNetwork timeout/error behavior might expose an existing XFlow retry or page-rebuild path under load.
- Jeff asked for either a proposed response to Adam or a statement that more information is needed, suggesting Adam should open a Discourse ticket and attach the relevant evidence if more detail is required.
Next Steps
- Frame any update to Jeff as a context refresh: related prior investigation exists, but the previous iOS SDK-side review did not reproduce duplicate client-side
open-accountcalls, so current logs/examples are needed before calling the new report the same issue or a regression. - If discussing REST impact, separate confirmed facts from hypothesis: confirmed prior non-prod iOS review did not reproduce duplicate client-side calls; current hypothesis is that REST timeout/error semantics may expose the existing XFlow model-state retry/rebuild path under production load.
- Prepare a concise proposed response to Adam that asks for a Discourse ticket with exact incident date/time, affected flow/page, app/XFlowSDK version, REST state if known, user journey logs, and examples needed to compare against
PDSPS-29371/PDIAP-11561.