EDS Block JSON Schema Change Not Reflecting on Existing Pages Until Manual Re-save.

We have a custom text block used across 100+ pages in AEM Edge Delivery Services.

Our block structure is based on ordered JSON fields, and recently we introduced a new field in the block. Because of this, all existing row indexes shifted by one, and we updated our JS/decorate() logic accordingly.

However, after deployment:

• The updated JS expects the new field order.

• Existing pages still render plain.html in the old structure/order.

• The new field is missing in the rendered output.

• modelFields/children count still reflects the old structure.

If we manually edit and re-save a page/block (even a minor change), the block gets regenerated correctly:

• modelFields gets updated

• children count becomes correct

• new field appears in the front

So currently it looks like all existing pages would need manual re-authoring/re-saving.

One additional complication in our setup:

• We cannot safely add new fields at the end either.

• Our tabs are structured like overview + common.

• The common tab appends 3 shared properties from a common JSON/model used across multiple blocks.

• Because of this merged structure, even adding a new field at the end of the overview tab changes the final rendered order and breaks existing production JS assumptions.

Questions:

1. Is there any supported way to refresh/rebuild existing block JSON/plain.html after schema changes?

2. Can decorate() trigger any regeneration or refresh of the block structure?

3. Are there any editor-side APIs, migration utilities, indexing jobs, or serialization refresh mechanisms for this use case?

4. How are such backward-compatible block structure changes usually handled in EDS when field ordering is important?

Looking for best practices to avoid manually touching/re-saving 100+ existing pages.