More accurately, ts_mon flushes on any request that happens >=60sec after the last flush on the same instance, regardless of what code processes that request. Do bots ever hit specific (non-default) version of the app?

It would also cross versions at the time of traffic migration, for the same reason.

If you don't hit specific versions in requests, would disabling ts_mon for the time of traffic migration for schema changes do the trick? It would only stop metrics for a couple of minutes, rather than waiting for tasks for 1h - which I assume might be much more disruptive.

By design, a bot that is running a task locks itself to the version that was used to get the task, e.g. 123-abc-dot-chromium-swarm.appspot.com. So yes, bots hit non-default version while running a task if the default version is changed while the task is running.

I see. Well, another way to do this is to roll only backwards-compatible schema changes. E.g. don't just delete or rename a field, but add a new one first, switch all usage to the new field, and after some time, delete the now unused field. It's more work, but eliminates the potential downtime.

Removing Internals>Metrics since this is not related to UMA or experiments.

it was a backward-compatible change from the proto perspective: add new field was added

what needs to be done is to store the config in the datstore in binary format, not text format. Buildbucket had the same problem and this solution worked well.
https://chromium-review.googlesource.com/c/367886/
https://chromium-review.googlesource.com/c/368355/

Swarming uses components.config's feature to store the config in the datastore, so fixing this bug requires changes to components.config
https://cs.chromium.org/chromium/infra/luci/appengine/components/components/config/remote.py?q=store_last_good+file:remote&sq=package:chromium&l=121