Suggestion: • what if we remove the requirement to always sync from main, to be able to merge a PR? It made sense in the first rush to make canvas, when things were presumably breaking/overlapping a lot, but maybe not so much anymore. The agent had to work for over 2 hours, waiting for each dependabot PR to re-update from main, re-run CI, merge, re-update from main, etc: https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1784998475582179?thread_ts=1784982841.208989&channel=C06QT0AGY4W&message_ts=1784998475.582179 (to note, I had also checked each PR manually; but merging multiple still can’t work without coming back and switching context to the next one)

yeah that's fair, let's do that i also want to see if we can have smarter subset selection for e2e tests on prs, bc the main risk is getting out of sync on the overall app behavior and failing those tests on main

Oh, by the way, some are flaky apparently

ah we should have an automation that sporadically checks the health of these tests and proposed fixes or deletions accordingly

I hear the concern that some would fail for “good” reason (that is, not so good, a real issue somewhere) I would propose on that to do it like we used to do on sdk: • tie a set of tests on labels • which are run only on release PRs • if something fails, investigate and fix separately, merge into release PR • => release

yes that sgtm

It would free us during regular times, and still be safe for releases

great point! love it

@bland-bear-604 remind me on Monday, we have a couple of Vasco PRs on release-please with pre-release tests, to understand the flow, review and merge, and then apply to upstream canvas too

🐾 Got it — reminder set for Monday 09:00. I’ll ping you about the Vasco release-please + pre-release-tests flow: understand it, review & merge the couple of PRs, then apply the same to upstream canvas. Prepped the context already (the label-gated release-only tests pattern from the SDK; canvas #1834/#1944, Vasco #1901/#1860; SDK precedents #4074/#4050), so we can jump straight in.