[Question] Is the validation behavior in keras.ops.conv_transpose intentionally different between symbolic and eager paths?

[AkshatRaj00]

Summary

I noticed a behavior mismatch in keras.ops.conv_transpose between the symbolic and eager execution paths.

Observation

It looks like the eager path fails earlier when input channels are invalid, while the symbolic path does not enforce the same validation in the same way and may allow the invalid shape to proceed further.

Expected behavior

If this difference is intentional, it would be helpful to document it clearly. If not, both paths should probably enforce the same input-channel validation so the user-facing behavior stays consistent.

Why this matters

This kind of mismatch makes debugging harder and can lead to backend-specific failures that are not obvious from the original error.

Question

Is this difference intentional, or should it be treated as a validation bug?

Optional note

If helpful, I can try to provide a minimal repro snippet for the exact behavior I’m seeing.

[starkmarkus]

I’d expect eager and symbolic to behave the same here from a user point of view.

If eager fails immediately on invalid input channels but symbolic lets it get further, that feels inconsistent rather than intentional.

Some difference in when the check happens is understandable, since symbolic execution can’t always validate everything right away. But the end result should still be the same: invalid conv_transpose input should fail clearly in both paths.

So unless there’s a reason for this split behavior, I’d treat it as a bug and make the validation consistent.

If helpful, I can also share a minimal repro for the exact case I hit.