feat: Update PDIAP-15838 and daily notes with AI-assisted analysis on Apollo removal and GraphQL cleanup strategy
This commit is contained in:
@@ -53,6 +53,12 @@ tags:
|
||||
- Jeff later relayed that Adam says the latest build is now activating REST correctly, so the story should shift back to the planned GraphQL-removal and related LaunchDarkly-toggle cleanup work.
|
||||
- Keep the real-device-only scenario in mind as a useful fallback hypothesis if the issue returns: environment-specific differences such as LaunchDarkly context, timing, or cached toggle state may explain behavior that does not reproduce in the simulator.
|
||||
- Adam was the reported source of the REST activation problem, and his side validates behavior on real devices.
|
||||
- Current codebase analysis suggests the main remaining source-level blockers are no longer transport selection but residual Apollo model/runtime coupling: `XFlow.Slot` usage in the page interactor/worker path, `NetworkClient` references still touched by init/session lifecycle, and Apollo/AppSync config surface that may still behave like public API.
|
||||
- Follow-up analysis suggested `XFlow.Slot` might be the only Apollo-generated production model still used outside the GraphQL-generated folder, but local trial changes surfaced additional Apollo-dependent models/build errors. Treat the `XFlow.Slot` simplification as a promising first step, not as a fully validated statement about the whole codebase.
|
||||
- The suggested simplification is to remove the current round-trip `stagedValues() -> [String: String] -> XFlow.Slot -> [String: String] -> XFlowUpdateSlotsRequest.slots` and instead pass `[String: String]` straight through to `XFlowUpdateSlotsRequest.slots`, keeping `SlotVariable: Encodable` in the REST model layer for request serialization.
|
||||
- The next AI follow-up should focus only on the first step and ask GitHub Copilot to corroborate residual Apollo-model dependencies by using `xcodebuild` failures, not just static reference search.
|
||||
- Apollo source-level cleanup appears sequenced as: replace `XFlow.Slot` with a transport-agnostic model first, decouple `XFlowInitManager` from `NetworkClient` while preserving current REST endpoint behavior, then remove runtime GraphQL code, project wiring, Apollo-only tests/scripts/docs, and finally treat any transitive PicoSDK Apollo dependency as a separate dependency-exit task.
|
||||
- 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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user