No, the problem is that the type completeness check has no memory across commits. So for each PR it needs to re-compute the type completeness of the head. so you have

1. commit A, merged after testing with pyright 1.1.372, type score 1.0
2. PR, comparing against commit A, recomputes with pyright 1.1.373, type score 0.976

If we wanted to catch these hases, we'd have to have something like codecov, i.e. a database for the type score per commit.
the upside of the current behavior is that a pyright update doesn't mark your PR as invalid even though your PR doesn't in itself decrease the type completeness …

@Bibo-Joshi I see. Can we not run a sanity check every month or so to see if the score dropped below 1.0?

Don't know if I'm too tired or if the output is not set correctly by the reusable action. Will have to retry someday

• Proof that the workflow picks up type completeness < 1:https://github.com/python-telegram-bot/python-telegram-bot/actions/runs/10853416139?pr=4466
• Proof that the workflow will pick up type completeness == 1 if run on master:https://github.com/python-telegram-bot/python-telegram-bot/actions/runs/10853469089 (the only problem here is that I use the "base completeness", i.e. the one of master which is crruntly < 1)
• Proof that this PR changes the type completeness to 1:https://github.com/python-telegram-bot/python-telegram-bot/actions/runs/10853484817

⇒ ready from my side :)