40 lines
1.5 KiB
Markdown
40 lines
1.5 KiB
Markdown
# XFlow Debugging
|
|
|
|
## Goal
|
|
|
|
Debug backend-driven flows without losing track of dynamic dependencies or misclassifying integration behavior.
|
|
|
|
---
|
|
|
|
## Stable Patterns
|
|
|
|
- XFlow screens are backend-driven, so UI can change without local code changes.
|
|
- Reproduction depends on:
|
|
- entry point
|
|
- authentication state
|
|
- backend configuration
|
|
- consumer integration path
|
|
- Not all entry points are reachable from visible UI; some require exploratory validation.
|
|
|
|
---
|
|
|
|
## Investigation Rules
|
|
|
|
- Confirm the entry point before comparing behavior.
|
|
- Separate service-driven behavior from client regressions.
|
|
- Confirm whether the issue reproduces in:
|
|
- sample app
|
|
- XFlow-only environment
|
|
- Fid4 / flagship
|
|
- authenticated vs non-authenticated state
|
|
- If a fix appears correct in the SDK but not in consumer validation, inspect the release chain before reopening root cause assumptions.
|
|
- When validating service/configuration changes, check the active flow-definition version in Cogstore before assuming a change is live in QA or Production.
|
|
- Do not assume a flow ID will exist in both Cogstore and Slate; verify which config system actually owns the flow you are inspecting.
|
|
|
|
---
|
|
|
|
## Historical Signals From Slack
|
|
|
|
- Historical debugging covered Next-button visibility, markdown modal analytics, modal presentation, slot updates, and SwiftUI lifecycle behavior.
|
|
- Multiple pipeline or dependency problems looked like XFlow issues until the build chain or consumer integration path was inspected more carefully.
|