Should Lightning be sending credential UUIDs to apollo in workflow chat?

The Problem

When a workflow is sent to apollo, credential UUIDs are removed.

This means that when workflows come BACK from apollo, Lightning must attempt to re-assign credential UUIDs onto the new workflow stucture. So long as node UUIDs are correctly preserved this is not too difficult, but changes to the workflow structure introduce a risk of credentials being dropped.

Indeed the new collab editor introduced a bug where credential ids were lost, causing much unhappiness: https://github.com/OpenFn/lightning/issues/4295

The Question

Is it correct that credential UUIDs are stripped from workflows before being sent to apollo?

@hanna-paasivirta is clear that we should avoid sending UUIDs into the model where possible. Not because of security concerns, but because the IDs a) bloat the input and b) must be preserved precisely and yet are at risk of being malformed c) have no intrinsic value to the model.

So our options are:

1. Lightning removes credential UUIDs before sending to apollo, then re-assigns credentials itself
2. Apollo accepts a workflow with credentials, and it handles UUID preservation (just like it handles step id preservation today)

History

I think this might be an accident of yaml generation in lightning.

I think that generating the workflow yaml to send to apollo comes from provisioner code, and the provisioner naturally removes credential UUIDs from the workflows.

In which case, the workflows that are sent to apollo have always been credential free by an accident of design. No-one chose this - it's just how the source yaml works and no-one realised the issue

I could be wrong - it's just something I saw on a screenshare.

I would like this theory confirmed. Also, if this is all the result of behaviour in the provisioner, and we decide we want to fix it, it's going to take some effort to find a solution which doesn't break github sync.

Next steps

@hanna-paasivirta should pair up with Elias, Farhan and/or Joe to work out the best strategy for handling this.

Maybe what we have right now is absolutely fine. Maybe we want to move/consolidate the effort. I don't know: the scope of this issue is to propose a plan.