Storage backend ID for TypeInstance from nested workflow is lost during TypeInstance upload

[pkosiec]

Description

The backend property in the TypeInstance upload payload from nested workflow is lost, when renaming output TypeInstance in upper workflow without specifying the backend again.

On PostgreSQL installation example:

1. Helm runner outputs Helm release TypeInstance:

capact-outputTypeInstances:
  - name: helm-release
    from: ti-artifact
    backend: helm-release-storage

2. PostgreSQL installation renames the TypeInstance:

capact-outputTypeInstances:
- name: psql-helm-release
   from: helm-release

Expected behavior

The backend property in the TypeInstance upload payload is preserved without needing to specify the backend again:

capact-outputTypeInstances:
- name: psql-helm-release
   from: helm-release
   # backend: helm-release-storage # this shouldn't be needed

Actual behavior

The backend property in the TypeInstance upload payload from nested workflow is lost, when renaming output TypeInstance in upper workflow:

capact-outputTypeInstances:
- name: psql-helm-release
   from: helm-release

Workaround: But if you specify the same backend again on the upper-level workflow, it works:

capact-outputTypeInstances:
- name: psql-helm-release
   from: helm-release
   backend: helm-release-storage # upper workflow also needs to require the same backend

Steps to reproduce

1. Create a local Capact cluster
2. Install Helm storage and apply policy

ACTION_NAME="bumpy-apricot-lanette" # your Action name which installed Helm storage backends
HELM_RELEASE_STORAGE_ID=$(capact act get $ACTION_NAME -ojson | jq '.Actions[0].output.typeInstances | map(select(.typeRef.path == "cap.type.helm.release.storage"))[0].id' -r)
HELM_TEMPLATE_STORAGE_ID=$(capact act get $ACTION_NAME -ojson | jq '.Actions[0].output.typeInstances | map(select(.typeRef.path == "cap.type.helm.template.storage"))[0].id' -r)

capact ti get $HELM_RELEASE_STORAGE_ID -oyaml
capact ti get $HELM_TEMPLATE_STORAGE_ID -oyaml

cat > /tmp/helm-storage-policy.yaml << ENDOFFILE
interface:
  default: # properties applied to all rules above
     inject:
       requiredTypeInstances:
          - id: ${HELM_TEMPLATE_STORAGE_ID}
            description: "Helm template"
          - id: ${HELM_RELEASE_STORAGE_ID}
            description: "Helm release"
  rules:
      - interface:
          path: cap.*
        oneOf:
        - implementationConstraints:
            requires:
            - path: cap.core.type.platform.kubernetes
        - implementationConstraints: {}
ENDOFFILE
capact policy apply -f /tmp/helm-storage-policy.yaml

5. Remove this line: https://github.com/capactio/hub-manifests/blob/fd4d2c961ddaa17a69d7a1e8f54da36894b0055e/manifests/implementation/bitnami/postgresql/install.yaml#L135

6. Populate new manifests

7. Create Action PostgreSQL Install (e.g. from Capact Dashboard)

8. Observe rendered workflow

   • Search for the upload-output-type-instances-step
   • See that the Helm Release backend data is empty (- alias: postgres-install-helm-install-helm-release\n attributes: []\n backend: null)

Revert the change from point no 3 and retry the 4-6 steps. See that the backend ID is properly rendered: - alias: postgres-install-helm-install-helm-release\n attributes: []\n backend:\n context: null\n id: e44dd2b8-cfbf-4f0a-aa2f-5e99ab827461