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.
67 lines
4.6 KiB
Markdown
67 lines
4.6 KiB
Markdown
---
|
|
type: daily
|
|
project: fidelity
|
|
date: 2026-04-21
|
|
status: active
|
|
focus: [rest-migration, xflow-swiftui-migration]
|
|
work-items: [pdiap-15838, pdiap-15836]
|
|
blockers: []
|
|
tags:
|
|
- daily
|
|
- fidelity
|
|
updated: 2026-04-21
|
|
---
|
|
|
|
# 2026-04-21
|
|
|
|
## Focus
|
|
|
|
- Continue `PDIAP-15838` Apollo-removal cleanup.
|
|
- Continue validating the Apollo-removal state.
|
|
- If time allows, publish new XFlow and XFlowViewMaker versions.
|
|
|
|
---
|
|
|
|
## Work Done
|
|
|
|
- Cleaned up the active production model layer so it no longer depends on Apollo-generated models for the current path.
|
|
- Removed the three `NetworkClient.shared.updateAppSyncURL(...)` calls from `XFlowInitManager` and removed `getAppSyncEndPoint()` after it became unused; the project still compiles.
|
|
- Updated the Confluence/root-cause document for the FTTransfer discussion so it now reflects the current recommendation.
|
|
- Removed the `ApolloGeneratedCode` runtime tree and its project wiring from XFlowSDK.
|
|
|
|
---
|
|
|
|
## Findings
|
|
|
|
- The model-decoupling step for `PDIAP-15838` is now in a cleaner state.
|
|
- The next focus should shift to the remaining Apollo-dependent runtime and infrastructure surface: init/session coupling through `NetworkClient`, Apollo-generated/runtime code that is no longer needed, and Apollo-specific tests/scripts/build wiring.
|
|
- Any Apollo dependency that remains only through PicoSDK should be treated separately from source-level cleanup.
|
|
- Copilot's focused runtime/init guidance says the safest next source-level step is to remove only the three `updateAppSyncURL(...)` calls from `XFlowInitManager`, then delete internal `getAppSyncEndPoint()` if it becomes unused, while leaving `NetworkClient.swift` and `XFlowInitManagerConfig.swift` in place temporarily as disconnected compatibility surface until later cleanup.
|
|
- After that step, no live init/session runtime wiring from `XFlowInitManager` into Apollo/AppSync remains; the remaining Apollo surface appears to be disconnected compatibility/runtime code plus later package/build/test cleanup.
|
|
- Follow-up scan says `GraphQL/NetworkClient.swift` now appears runtime-dead for production, `GraphQL/ApolloGeneratedCode` appears unreferenced by production runtime after model cleanup, and the safest next step is to remove `NetworkClient.swift` first, then validate before removing `ApolloGeneratedCode`.
|
|
- Broader Apollo cleanup has now removed `NetworkClient.swift`, `ApolloGeneratedCode`, Apollo-specific test files/mocks, and related project-file entries. Current reported state says production code has zero live Apollo imports/references and retained REST behavior, while remaining follow-up work is package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`.
|
|
- Test-target cleanup is now also in a good state: a minimal update to `XFlowTransportSelectionTests.swift` removed obsolete GraphQL/Apollo assertions, preserved REST-oriented coverage, and left no remaining non-environment test-target compile errors.
|
|
- The latest cleanup pass also removed the remaining direct Apollo package/build references, so the story is now in a cleaner post-removal state and ready for consumer-side validation from Fid4.
|
|
- The current FTTransfer communication should say the primary fix is the dismissal adjustment in the UIKit hosting path; FTTransfer-side improvements are secondary and not strictly required to reproduce the same visual behavior.
|
|
- After the `ApolloGeneratedCode` removal, local compilation still succeeds for David; the Copilot-reported `ApexKitSwiftUI` blocker should be treated as environment-specific noise unless it becomes reproducible in the real local build.
|
|
- No live production Apollo runtime references remain in `XFlowSDK/XFlowSDK`; the next cleanup surface is deferred test references plus any intentionally retained AppSync compatibility APIs.
|
|
|
|
---
|
|
|
|
## Next Steps
|
|
|
|
- Confirm whether `NetworkClient.swift` still has any live production callers or can now be treated as removable runtime dead code.
|
|
- Confirm whether `XFlowInitManagerConfig.swift` AppSync getters are truly compatibility-only or still externally used.
|
|
- Identify the runtime Apollo files that can now be removed safely after the model and init cleanup.
|
|
- Remove Apollo-only tests, mocks, codegen scripts, and build wiring once runtime references are gone.
|
|
- Treat any transitive PicoSDK Apollo dependency as a separate dependency-exit step.
|
|
- Continue cleanup by removing GraphQL/Apollo-era test references and related test-only helpers without changing production runtime behavior.
|
|
- Continue validating the Apollo-removal state today.
|
|
- If time allows, publish new XFlow and XFlowViewMaker versions.
|
|
|
|
---
|
|
|
|
## Blockers
|
|
|
|
- None currently.
|