Hey Hung, How are you doing today? this kind of schema change feels like it should be handled smoothly, especially when going from INT to FLOAT, which is usually a safe and upward-compatible change. But in DLT, things are a bit stricter because it tracks schema history closely for reliability. Even with autoMerge.enabled, Delta Live Tables won’t auto-merge incompatible types like INT and FLOAT unless everything lines up perfectly—including any schema hints, expectations, and previous metadata. Sometimes even a tiny mismatch in how the schema is inferred or cast can cause this conflict to persist. If casting to FLOAT didn’t help, and casting back to INT doesn’t work either, it's likely that the existing Delta metadata is locked into expecting INT, and DLT is refusing to merge to avoid potential data issues. Dropping the target table is usually the cleanest way out when this happens—DLT will rebuild it with the new schema. I know it’s not ideal, but it’s often the quickest fix. Let me know if you want help scripting that out safely!

Regards,

Brahma