Be robust against startup during a migration

[glasserc]

Currently the listener runs at startup and makes some database queries to try to figure out what the "current" version of the megaphone version for monitor/changes should be. Unfortunately, during a migration, the application comes up before the migration runs, and the listener may not be able to execute the queries it wants to. Instead, is it maybe possible to do queries in a "just-in-time" fashion on a per-request basis, perhaps in a ResourceRead event handler?

/cc @leplatrem @autrilla

[leplatrem]

I was going to suggest to ApplicationCreated event, but it looks like bootstrap() triggers it too

Another approach would be to initialize stuff on the first request (listen to NewRequest event, initialize, remove listener).

Also, do you think that this would explain the Sentry about the missing DB table that we had during the migration?

[glasserc]

I was going to suggest to ApplicationCreated event, but it looks like bootstrap() triggers it too

In fact ApplicationCreated is what we listen to right now.

Also, do you think that this would explain the Sentry about the missing DB table that we had during the migration?

Yes, Sentry messages about objects not being present are probably due to this kind of migration strategy. The Sentry errors don't always indicate where the calling code was, but for kinto-writer, it could certainly be this. Of course, other Kinto instances could encounter this same error from normal operation during the migration -- I'm not sure if the "new" instances are already serving traffic when we run the migrate command.