dateField saveInto logic executed on invalid date entered

I'm not sure why you're expecting anything different to happen - your SaveInto attempts to save the value of the entered date, fails, and then executes the other saves as normal (executing the logical path matching local!tempDate being blank, it looks like).

Do you have some reason to believe it shouldn't work like this?  I don't personally know of any documentation suggesting that when one member of the saveInto array is invalid, that subsequent saves shouldn't complete executing.

Please see if the attached sample (my own form that's similar to your original one but with some added stuff) helps clarify on this at all for you...

load(
  local!tempDate: null(),
  local!lastInteractionText: null(),
  local!interactionsCounter: 0,
  
  a!sectionLayout(
    contents: {
      a!dateField(
        value: local!tempDate,
        saveInto: {
          local!tempDate,
          a!save(
            local!lastInteractionText,
            if(
              rule!GBL_isBlank( save!value ),
              "Last interaction did not successfully save a valid date.",
              "Last interaction saved a value successfully."
            )
          ),
          a!save(
            local!interactionsCounter,
            local!interactionsCounter + 1
          )
        }
      ),
      
      a!textField(
        label: "Date Value...",
        value: local!tempDate,
        disabled: true()
      ),
      a!textField(
        label: "Status...",
        value: local!lastInteractionText,
        disabled: true()
      ),
      a!textField(
        label: "Interaction Count...",
        value: local!interactionsCounter,
        disabled: true()
      )
    }
  )
)

I'm not sure why you're expecting anything different to happen - your SaveInto attempts to save the value of the entered date, fails, and then executes the other saves as normal (executing the logical path matching local!tempDate being blank, it looks like).

Do you have some reason to believe it shouldn't work like this?  I don't personally know of any documentation suggesting that when one member of the saveInto array is invalid, that subsequent saves shouldn't complete executing.

Please see if the attached sample (my own form that's similar to your original one but with some added stuff) helps clarify on this at all for you...

load(
  local!tempDate: null(),
  local!lastInteractionText: null(),
  local!interactionsCounter: 0,
  
  a!sectionLayout(
    contents: {
      a!dateField(
        value: local!tempDate,
        saveInto: {
          local!tempDate,
          a!save(
            local!lastInteractionText,
            if(
              rule!GBL_isBlank( save!value ),
              "Last interaction did not successfully save a valid date.",
              "Last interaction saved a value successfully."
            )
          ),
          a!save(
            local!interactionsCounter,
            local!interactionsCounter + 1
          )
        }
      ),
      
      a!textField(
        label: "Date Value...",
        value: local!tempDate,
        disabled: true()
      ),
      a!textField(
        label: "Status...",
        value: local!lastInteractionText,
        disabled: true()
      ),
      a!textField(
        label: "Interaction Count...",
        value: local!interactionsCounter,
        disabled: true()
      )
    }
  )
)

Thanks Mike for details. I agree with you the way its expected to work.

Then I think its better to check for entered date value for null before doing any save activities if the entered date value as any impact.

Do you have a particular use case where the current behavior is producing unexpected or undesired results, out of curiosity?

We have service call on entering date to do certain validations in the backend and we observed service errors saying date should not be null.

Since date field was mandatory in the interface we were thinking in what scenarios date can go blank. Then realized user entered invalid date by typing instead of selecting from calendar. That triggered service calls with no or null date.

Remember that a user can also clear out a date field, which has the same effect as entering an invalid date (other than not showing an error message on the date picker component when blank, anyway).  Therefore if this is an issue for you I'd suggest perhaps moving your verification service calls to a button or Rich Text link, if possible, where you could control when the user is able to do it, and not enable it until a valid date is entered (and any other on-form data that should nominally be required first).

Then again maybe just wrapping the service calls in a null check would work, if you don't want to make the user perform an additional click.

Yes, we added logic to perform date validation before executing any saveInto logic