david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: update daily logs and work items for 2026-04-29; refine Apollo removal strategy and address FTTransfer issue

Browse Source
This commit is contained in:
David Delagneau
2026-04-29 07:39:55 -06:00
parent d3c5d8f7de
commit fa1ab57de8
6 changed files with 99 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
project-knowledge/02-work-items/pdiap-15838.md
View File

@@ -8,7 +8,7 @@ systems: [xflowsdk]
workstreams: [rest-migration]
people: [jeff-dewitte, bruce-meeks, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas]
related: [launchdarkly, github-copilot]
updated: 2026-04-28
updated: 2026-04-29
tags:
- work-item
- fidelity
@@ -19,8 +19,8 @@ tags:
## Status
- Active Apollo-removal cleanup and validation
- PR merge should wait until the REST backend is deployed to production because GraphQL fallback is still needed before then
- Draft PR open for internal review
- PR merge should wait 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
- Sized at `8` points
---
@@ -72,6 +72,11 @@ tags:
- Apollo may still remain in the pod graph transitively through PicoSDK even after source-level cleanup, so "Apollo removed" should be framed carefully unless the dependency graph is also cleared.
- Latest local follow-up suggests `SampleApp` depends on `PicoSDK`, and that transitive dependency may still be the practical reason Apollo remains in the pod graph. Newer `PicoSDK` versions no longer depend on Apollo, but the upgrade path does involve real breaking changes. The current investigation is to determine how `SampleApp` can absorb those changes by comparing against how `Fid4` currently uses `PicoSDK` for the two specific flows that still depend on it.
- Jeff later confirmed that this `PicoSDK` / `SampleApp` cleanup is in scope for `PDIAP-15838` because Apollo needs to be removed from the project, including the transitive sample-app path. Keep the nuance explicit that this update affects `SampleApp`, not the `XFlowSDK` production runtime directly.
- David updated `SampleApp` to use the newer `PicoSDK` path, removing Apollo from the transitive sample-app dependency path and re-enabling the FGO and FidFolios flows for testing in `SampleApp`.
- The `SampleApp` Pico changes now more closely mirror how Pico is already used in Fid4.
- A draft PR has been opened for `PDIAP-15838 - Remove Apollo for iOS`; after internal review, the link should be sent to Bruce.
- Internal review found and resolved `PicoSDK` integration concerns: `TransactionContextManager(resolver:)` handles Pico setup internally in `PicoSDK 4.3.18` through lazy resolver-based initialization, the resolver already exists on `XFlowSampleAppViewModel`, and `PicoInterface` was minimally patched so the async completion path avoids a strong `self` capture and returns through `MainActor.run` for UI-state safety.
- The REST kill-switch removal is intentional for permanent GraphQL deprecation, but merge timing is gated: the previous REST-toggle implementation should first be QA-tested and active in production with REST enabled for all consumers for 30 days without issues.
- Merge sequencing is now explicitly gated by backend production readiness: Bruce reinforced that the GraphQL/Apollo removal PR should not merge until the backend is in production because GraphQL fallback is still needed before then.
- Bruce clarified that the current SDK-side updates are not REST behavior changes; the functional REST/backend fix is on the Flagship/Fid4 side, while SDK updates are cleanup, more graceful error handling, logging, and replacing a deprecated logger interface.
- Bruce asked whether iOS Fid4 has a release-build optimization or code-minification concept comparable to Android; treat this as a validation/build-configuration question until clarified, not as evidence of a known iOS minification issue.