The error refers to “input17”; clicking on it brings up the marge node code - line 8 has range(16) i.e. produces [0… 15] and then 1 is added by the f-string.
So where is “input17” coming from??
NB This is not the 1st time this has happened, but given the dynamic nature of the merge’s response to typing in the “number of inputs” field I wasn’t previously sure it wasn’t in some weird intermediate state.
The merge was created with 2 inputs, increased to 20 via the #inputs field and then after wiring up inputs 17-20 incl were deleted.
If I save the code shown, that particular error goes away, suggesting there is some lurking update that wasn’t previously processed.
TF then complains (in the error list) that “ranks of all input tensors should match”. This is now traced to the categorical inputs “type” and “survey” which are automatically one-hot encoded (as @robertl stated)
Trying to put them back in, the component is “locked”… but I can still add another (unnumbered) input. If I then update the range limit on line 8 to recognise the new input, a new keyerror appears for “input15”, i.e. the lack of a number on adding it is actually a real naming error that prevents the input being recognised.
Looks like input creation, deletion etc. happens differently on the diagram vs in the settings & the code isn’t catching up, which suggests an additional synch/update event issue.
** UPDATE ** Hmmm… should the categorical inputs be reshaped for input to the merge? to deal with the rank issue??