gitStream miscategorizes the changes in PR

[avivtabak]

Description of the problem
Lately (about the last month) I noticed a wried behavior with gitStream in our Repo where it is auto-approving PRs.

For example (can't provide link to the PR since it's a private repo):
When I opened a PR for a python file client.py (+16 lines added -1 removed = total of 17 lines) the gitStream bot auto-approved the CR.
The bot label it as a safe-changes, so i tried to validate the conditions for save_changes automation, but couldn't find any reason to categorize the PR as safe-changes

the condition is:
{{ is.safe }}

where:

docs: {{ files | allDocs }}
tests: {{ files | allTests }}
asset: {{ files | match(regex=r/\.(png|svg|gif|css)$/) | every }}
formatting: {{ source.diff.files | isFormattingChange }}
safe: {{ is.docs or is.tests or is.asset or is.formatting }}

Steps to reproduce the behavior:

1. The .cm automation file:

# -*- mode: yaml -*-
manifest:
  version: 1.0

automations:
  safe_changes:
    if:
      - {{ is.safe }}
    run:
      - action: approve@v1

      - action: add-label@v1
        args:
          label: 'safe-changes'

  small_changes:
    if:
      - {{ is.small_changes }}
    run:
      - action: approve@v1

      - action: add-label@v1
        args:
          label: 'small-changes'

is:
  docs: {{ files | allDocs }}
  tests: {{ files | allTests }}
  asset: {{ files | match(regex=r/\.(png|svg|gif|css)$/) | every }}
  formatting: {{ source.diff.files | isFormattingChange }}
  safe: {{ is.docs or is.tests or is.asset or is.formatting }}

  additions: {{ branch.diff.files_metadata | map(attr='additions') | sum }}
  deletions: {{ branch.diff.files_metadata | map(attr='deletions') | sum }}
  small_changes: {{ (is.additions + is.deletions) <= 10 }}

2. The PR URL (as it contains the repo and PR identifiers)
   Can't provide as its a private repo, but can be reproduced with any dummy repo with python file

Expected behavior

Shouldn't give any label as it's not match the automation conditions

Screenshots

[PavelLinearB]

Hi @avivtabak
We have released a fix to our Python formatter that caused this issue.
Can you please verify this is fixed on your end, too?

Thanks!