Race issue on forward port (again)

[xmo-odoo]

Observed on odoo/odoo#262603 / odoo/enterprise#116090 / odoo/enterprise#116082:

• fwbot created the forward port on 2026-05-04, with a PR creation failure leading to a dupe enterprise PR

  • at 15:55:28,575 the opened event on 116082 arrived, and was ignored because the forward porting was locking up the table
  • at 15:55:39,114 the closed event (from deleting the ref) arrived
  • at 15:55:39,117 POST /pulls finally returned an error
  • at 15:55:39,139 because the PR didn't exist (due to ignoring the opened event) a fetch was triggered
  • due to 6910bbe not being deployed, the PR was not seen as closed

  Resulting in that dupe remaining open alongside its two "correct" siblings

• on 2026-05-11 a check had the same issue, due to 6910bbe not being deployed it updated the state but not the closed flag

• finally on 2026-05-18 the PR was closed for real and the batch could proceed

However looking at the logs:

• we checked if the batch could be forward ported a bunch on 2026-05-04, those failed because 116082 had no parent
• we checked a bunch again on 2026-05-07, this is when 262603 and 116090 were r+d, they failed for the same reason
• on 2026-05-18, 116082 was closed frfr on 06:27:01,269, no fw check happened after that
• at 07:25:15,939 batch 523156 was staged (staging 162926)
• at 08:45:06,446, batch 523156 was merged
• no post-merge forward port happened either

So there should probably be a fw trigger when a batch gets unblocked as well as when statuses get updated? And most likely a merge should always trigger an fw check in case we missed previous scenarios

[xmo-odoo]

Shower thought: fire off an fw check on every PR state change?

Also maybe look into quint and see if it's possible to model the logic for forward porting?