fix(push-publish): apply field data-type change on the receiver (#36636)

[nollymar]

Summary

Fixes #36636.

DeterministicIdentifierAPIImpl.resolveName now includes the field's dataType in the id seed (variable : typeName : dataType.value). When a Content Type field is deleted on the sender and immediately re-created with the same velocity variable but a different data type, the receiver's ContentTypeAPIImpl.transactionalSave now sees the incoming field as a different id from the old one and routes it through delete-then-insert — instead of update, which would overwrite the incoming dataType/dbColumn with the existing field's values in FieldFactoryImpl.dbSaveUpdate.

Test plan

• DeterministicIdentifierAPITest — added coverage for the new dataType-in-seed input.
• Manual push-publish reproduction per issue Push publish silently discards a field's data-type change when a field is deleted and re-added with the same variable name #36636 (Postgres, JSON storage):
  • Create a Content Type with a Text field myField on the sender and content records carrying values for it.
  • Delete myField and re-create it with a different data type. Set a new value on the content.
  • Push publish the Content Type to the receiver.
  • Verify the receiver's field is saved with the new data type (previously it kept the sender's original — this PR fixes that).
  • Push publish the affected content records to the receiver (a separate step — a Content Type push does not enqueue that type's content records).
  • Verify the receiver's content shows the new value.

Data impact (unchanged from the issue's analysis)

Changing a field's data type is inherently destructive for that field's stored content:

• The recreated field of a different type gets a new empty column via FieldFactoryImpl.nextAvailableColumn, so existing values in the old column are not migrated.
• On the sender, CleanUpFieldReferencesJob wipes the old column and the contentlet_as_json entry for that variable when the field is deleted, so the sender loses the pre-existing values at that moment.
• On the receiver, a Content Type push applies the new field but does not carry content — the receiver's content records keep their pre-change state (missing the new-type value) until the content itself is pushed. A follow-up content push is required to reflect the new values on the receiver.

This PR does not attempt to migrate values; it just ensures the data-type change is applied on the receiver instead of silently dropped.

🤖 Generated with Claude Code

[claude]

Claude finished @fabrizzio-dotCMS's task in 4m 36s —— View job

---

Code Review — PR #36746

• Read the diff (DeterministicIdentifierAPIImpl + test)
• Trace blast radius of the seed change through FieldFactoryImpl / push-publish
• Assess test coverage

New Issues

No blocking issues found. The change is small, well-scoped, and backed by meaningful tests.

Notes (non-blocking):

• 🟡 Medium: DeterministicIdentifierAPIImpl.java:329-332 — The seed change is global to all field id generation, not just the delete-recreate scenario. This is safe in practice because a field's deterministic id is only computed when throwAwayField.id() == null (FieldFactoryImpl.java:339), and push-publish bundles carry existing fields with their already-stored ids — so pre-existing fields are matched by id and never re-hashed on the receiver. Worth confirming you're comfortable that any newly created field on an upgraded node now hashes differently than the same field created on a pre-upgrade node (mixed-version cluster edge case). Both sides on the same version stay consistent, so normal push-publish is unaffected.

• 🟡 Medium: DeterministicIdentifierAPIImpl.java:329 — field.dataType() also returns non-null values for non-data fields (SYSTEM for constant/binary/divider/tab per DataTypes.getDataType, NONE for others), so their seeds now include system_field/none. Harmless — it just changes the hash consistently on both sides — but the id for these field types will differ from ids generated by the old code. Same mixed-version caveat as above; no action needed if a coordinated upgrade is assumed.

Observations

• The null-dataType fallback to the legacy variable:typeName seed (line 330-332) is a good touch — it keeps ids stable for any field whose dataType() is null and is covered by the noDataTypeField mock assertion at DeterministicIdentifierAPITest.java:852-859.
• Test coverage is solid: Test_ResolveName_Seed_Includes_DataType_When_Present (unit-level seed), Test_Delete_And_Recreate_Field_With_Different_DataType_Generates_New_Id (id divergence), and Test_ContentType_Save_Applies_DataType_Change_When_Field_Id_Differs (the actual receiver flow — asserts the old field is dropped and the new data type is applied). These map directly to the failure mode in Push publish silently discards a field's data-type change when a field is deleted and re-added with the same variable name #36636.
• The existingField update path in FieldFactoryImpl.dbSaveUpdate (lines 315-316) still force-copies the old dataType/dbColumn; this PR correctly sidesteps that by making the incoming field resolve to a different id so it takes the insert path rather than update. That reasoning holds.

Nothing here blocks merge.

• worktree-issue-36636-field-datatype-change