resource/pingone_davinci_flow: prepare exporter for multi-outcome node routing - #127
Merged
Conversation
findFieldByPath now falls back to a struct's AdditionalProperties map (exact key, then lower-first-letter camelCase) when a named-field lookup misses, so YAML attributes can source fields the SDK hasn't typed yet (e.g. DaVinci node data outcomes) with zero custom Go code. Every call site (processOneAttribute, convertSliceToMap, processTypeDiscriminatedBlock) inherits this for free since they all route through findFieldByPath.
…hema Declares outcomes (list of id/result/label) under GraphData.Elements.Nodes.Data in flow.yaml, resolved via the AdditionalProperties fallback added in the previous commit since the SDK has no typed Outcomes field yet. Zero formatter changes needed -- list-with-nested_attributes rendering already generic. Inert until terraform-provider-pingone adds provider-side schema support for multi-outcome node routing; groundwork so the exporter activates the moment the provider ships it. Adds processor + HCL formatter tests driven by the real flow.yaml definition (via schema.Registry) rather than a synthetic schema, to catch drift between the fallback and the actual attribute declaration.
Regression Test Results
✅ No regressions detectedAll export configurations produced compatible output. Generated by regression workflow • View run |
…ps outcomes Points the outcomes block's comment at the PR description, which lists what to re-check once terraform-provider-pingone accepts the attribute: field naming/casing on the regenerated SDK struct, list vs set on the provider schema, and terraform_name alignment.
Regression Test Results
✅ No regressions detectedAll export configurations produced compatible output. Generated by regression workflow • View run |
…utcomes field terraform-provider-pingone#1342 and pingone-go-client#86 merged the outcomes field upstream (CDI-1370's spec fix landed). pingone-go-client v0.12.0 now types DaVinciFlowGraphDataResponseElementsNodeData.Outcomes as a named field, so the AdditionalProperties fallback added for this attribute goes dormant -- resolution goes through the normal named-field path in findFieldByPath, exactly as anticipated. Updated davinci_flow_outcomes_test.go to construct the typed field directly (matching how a real API response now unmarshals) instead of stuffing outcomes into AdditionalProperties, which no longer reflects reality. The terraform-provider-pingone fix (PR #1345) is merged to main but not yet in a tagged release, so applying HCL with an outcomes block still fails against the current provider release -- noted in the changelog entry.
The follow-up-verification framing is stale now that terraform-provider-pingone#1342 / pingone-go-client#86 have both resolved. Points at PR #127's description for the current release status instead of restating open questions that are now answered.
Regression Test Results
✅ No regressions detectedAll export configurations produced compatible output. Generated by regression workflow • View run |
Regression Test Results
✅ No regressions detectedAll export configurations produced compatible output. Generated by regression workflow • View run |
Rephrase to assume the terraform-provider-pingone release containing outcomes support (terraform-provider-pingone#1342, merged via #1345) will be out by the time this PR ships -- this repo is holding merge until that release lands.
Regression Test Results
✅ No regressions detectedAll export configurations produced compatible output. Generated by regression workflow • View run |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
showFormnode with "Save" and "Resend" exit paths) currently break when exported to HCL and re-applied, because the node'soutcomesarray is dropped on the round trip while edges referencing those outcome IDs (multi_value_source_id) are preserved — the applied flow ends up routing to outcome IDs that don't exist.outcomesfield on DaVinci flow node data, so it generated neither a typed SDK field nor a Terraform provider schema attribute. Update: the full upstream chain has now shipped —pingone-go-clientv0.12.0 added a typedOutcomesfield, andterraform-provider-pingonemerged schema support in PR #1345 (merged 2026-07-16, not yet in a tagged release). This PR now includes the SDK bump to pick up the typed field.main, awaiting a tagged release).Upstream fix verified — all three follow-up items confirmed correct
The three items originally flagged for re-verification once the provider shipped support have all been checked against the real merged code:
pingone-go-clientv0.12.0 addsOutcomes []DaVinciFlowGraphDataResponseElementsNodeDataOutcome— exactly the PascalCase name this PR'ssource_path: Outcomesassumed.schema.ListNestedAttribute(types.ListType), matching this PR'stype: list.terraform_namealignment — ✅ confirmed. The provider's attribute is literally namedoutcomes, matching this PR'sterraform_name: outcomes.No changes were needed to
flow.yaml'soutcomesblock. The only change required was bumpinggo.modtopingone-go-client v0.12.0(this commit) so theAdditionalPropertiesfallback ininternal/core/processor.gogoes dormant for this field and resolution goes through the normal named-field path instead — verified directly: unmarshaling a raw JSON payload with anoutcomeskey now populates the typedOutcomesfield, notAdditionalProperties. The existing test (davinci_flow_outcomes_test.go) was updated to construct the typed field directly rather than the no-longer-representativeAdditionalPropertiesstuffing it used before.Still blocking end-to-end:
terraform-provider-pingone's fix (PR #1345) is merged tomainbut not yet in a tagged release (latest is still v1.20.0). Exporting a flow with multi-outcome nodes today will produce HCL the currently released provider version cannot apply — this will resolve itself once a new provider version ships, with no further changes needed here.Changes
AdditionalPropertiesfallback to the processor's field resolution (internal/core/processor.go): when a YAML attribute'ssource_pathdoesn't match a named SDK struct field, resolution now falls back to a lookup in that struct'sAdditionalPropertiescatch-all (exact key, then lower-first-letter camelCase). This isn'toutcomes-specific — it benefits any current or future SDK field that lags behind its JSON shape, with zero custom Go code required per the repo's schema-driven architecture.outcomesattribute todefinitions/pingone/davinci/flow.yamlunder node data (type: list, nestedid/result/label), which resolves via the fallback above.outcomescontinue to export unchanged, and no HCL currently generated changes shape, since the Terraform provider doesn't yet accept the attribute.go.mod/go.sumbump topingone-go-client v0.12.0to pick up the typedOutcomesfield once it existed upstream (see verification section above).Test plan
AdditionalPropertiesentry resolves via the fallback — Verified by unit tests ininternal/core/processor_test.goAdditionalProperties-field structs, nil maps, and absent keys all behave identically to pre-change code — Verified by unit tests ininternal/core/processor_test.goflow.yamldefinition, loaded via the schema registry, correctly renders anoutcomesblock for a node that has it and omits the attribute for a node that doesn't, in both HCL and the processor's intermediate representation — Verified byinternal/core/davinci_flow_outcomes_test.gogo vet, andvalidate-definitionspass with no regressions — Verified bymake test,make vet,go run ./tools/validate-definitions definitions/🤖 Generated with Claude Code