Hi @AanchalSoni,

No problem asking questions. That's what this forum is for.

You don’t need a brand‑new checkpoint for every tiny code change, but you should treat a checkpoint as belonging to one specific logical stream configuration.

A more precise rule of thumb is that it is safe to reuse the same checkpointLocation when the query is logically the same, such as having the same input, stateful operators (agg/join/dedup), output mode, keys, and watermarks. Alternatively, it is safe when you are just restarting the cluster or rerunning the same notebook cell.

Use a new checkpointLocation (or delete the old one) when you change output mode (append ↔ complete/update) or add/remove stateful operations (aggregations, stream‑stream joins, mapGroupsWithState, dedup with watermark), or when you significantly alter the query shape in a way that affects state.

In your specific use case ("I’m just validating transformations, trying out different versions"):

• Yes, that usually does mean using a different checkpoint path per meaningfully different version of the stream, instead of reusing the same one and fighting mysterious errors.
• The overhead is mostly a few extra small directories and files in storage. For exploratory work, that cost is negligible compared to the cost of your time and cluster.

A practical pattern to keep it manageable:

/Volumes/.../checkpoints/accounts/        # base
  display_v1/
  display_v2_with_agg/
  write_to_delta_append/
  write_to_delta_complete/