|
| 1 | +# Copyright (C) 2026 Percona LLC |
| 2 | +# |
| 3 | +# This program is free software: you can redistribute it and/or modify |
| 4 | +# it under the terms of the GNU Affero General Public License as published by |
| 5 | +# the Free Software Foundation, either version 3 of the License, or |
| 6 | +# (at your option) any later version. |
| 7 | +# |
| 8 | +# This program is distributed in the hope that it will be useful, |
| 9 | +# but WITHOUT ANY WARRANTY; without even the implied warranty of |
| 10 | +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
| 11 | +# GNU Affero General Public License for more details. |
| 12 | +# |
| 13 | +# You should have received a copy of the GNU Affero General Public License |
| 14 | +# along with this program. If not, see <https://www.gnu.org/licenses/>. |
| 15 | + |
| 16 | +"""Create the Celery beat schedule tables ahead of the processes that read them. |
| 17 | +
|
| 18 | +The ``sqlalchemy_celery_beat`` tables are created by no alembic revision in any of |
| 19 | +SEP's three migration tracks: the library builds them itself, from |
| 20 | +:meth:`sqlalchemy_celery_beat.session.SessionManager.prepare_models`, which |
| 21 | +:class:`~sqlalchemy_celery_beat.schedulers.DatabaseScheduler` reaches on beat's |
| 22 | +own startup. Every service that seeds periodic tasks during its lifespan |
| 23 | +(:func:`app.core.celery.utils.init_periodic_tasks_db`) therefore reads tables |
| 24 | +whose only creator is a process ordered *behind* it, and on a database with no |
| 25 | +schema the read fails. |
| 26 | +
|
| 27 | +Driving the library's own bootstrap from a step ordered ahead of those services |
| 28 | +breaks the cycle while leaving the tables the library's to define — nothing here |
| 29 | +declares their shape. This module is kept beside :mod:`app.core.celery.db` rather |
| 30 | +than inside it so importing it does not construct that module's asynchronous |
| 31 | +engine, which resolves the same setting through a driver |
| 32 | +:meth:`~sqlalchemy_celery_beat.session.SessionManager.prepare_models` cannot use. |
| 33 | +""" |
| 34 | + |
| 35 | +import logging |
| 36 | +import logging.config |
| 37 | +from time import sleep |
| 38 | + |
| 39 | +from sqlalchemy.engine import Engine |
| 40 | +from sqlalchemy.exc import OperationalError |
| 41 | +from sqlalchemy_celery_beat.session import SessionManager |
| 42 | + |
| 43 | +from app.core.config import settings |
| 44 | + |
| 45 | +logger = logging.getLogger(__name__) |
| 46 | + |
| 47 | +STORE_READINESS_POLL_INTERVAL = 1.0 |
| 48 | +"""Seconds between connection attempts while the beat store is unreachable.""" |
| 49 | + |
| 50 | + |
| 51 | +def _wait_for_store(engine: Engine) -> None: |
| 52 | + """Block until the beat store accepts a connection. |
| 53 | +
|
| 54 | + The side-car's three alembic one-shots wait on ``SEP_DB_HOST``/``SEP_DB_PORT`` |
| 55 | + in the shell, because that is the database they upgrade. The beat store is |
| 56 | + whatever ``CELERY.beat_dburi`` resolves to, and a deployment may point it at a |
| 57 | + separate database, so readiness is probed against the URL this process will |
| 58 | + actually dial rather than against a host named in the program table. |
| 59 | +
|
| 60 | + The wait is unbounded, matching those three shell loops. A bounded one could |
| 61 | + expire while the store was merely slow, and the caller runs as a one-shot that |
| 62 | + is never re-run, so its sentinel could then never appear — leaving every |
| 63 | + program gated on it waiting for the life of the container. What bounds the |
| 64 | + observable behaviour instead is the gate in front of each API program, and the |
| 65 | + healthcheck, which reports the missing sentinel either way. |
| 66 | +
|
| 67 | + ``prepare_models`` retries too, but only for the check-then-create race it was |
| 68 | + written for: ten attempts with sub-second backoff, which a database that has |
| 69 | + not finished starting outlasts. |
| 70 | +
|
| 71 | + :param engine: The synchronous engine for the resolved beat store. |
| 72 | + :raises DBAPIError: On a connection failure that is not an |
| 73 | + ``OperationalError``, which is raised on the first attempt rather than |
| 74 | + retried — only an ``OperationalError`` is treated as "not up yet". |
| 75 | + """ |
| 76 | + while True: |
| 77 | + try: |
| 78 | + with engine.connect(): |
| 79 | + return |
| 80 | + except OperationalError: |
| 81 | + # Host and port only: the resolved URL carries the store's password. |
| 82 | + logger.info( |
| 83 | + "Waiting for the Celery beat store at %s:%s", |
| 84 | + engine.url.host, |
| 85 | + engine.url.port, |
| 86 | + ) |
| 87 | + sleep(STORE_READINESS_POLL_INTERVAL) |
| 88 | + |
| 89 | + |
| 90 | +def bootstrap_beat_schema() -> None: |
| 91 | + """Create the ``sqlalchemy_celery_beat`` schedule tables if they are absent. |
| 92 | +
|
| 93 | + The store and schema are resolved exactly as |
| 94 | + :meth:`sqlalchemy_celery_beat.schedulers.DatabaseScheduler.__init__` resolves |
| 95 | + them, so beat and this step cannot disagree about where the tables belong. |
| 96 | + ``prepare_models`` checks before it creates, so a store that already carries |
| 97 | + them is left alone. |
| 98 | +
|
| 99 | + The scheduler's pool options are deliberately **not** forwarded. On this |
| 100 | + non-forked path the library pins ``NullPool`` and drops every |
| 101 | + ``pool``-prefixed key, so such an option is either ignored or — for a key |
| 102 | + outside that prefix, such as ``max_overflow`` — rejected outright by |
| 103 | + ``create_engine``. Neither outcome can configure anything, and the second |
| 104 | + would fail this step on a documented, validated setting. |
| 105 | +
|
| 106 | + :raises DBAPIError: When the store refuses a connection for a reason other |
| 107 | + than not being up yet, or when creating the tables fails after the |
| 108 | + library has exhausted its own retries. The family is ``DBAPIError`` |
| 109 | + rather than ``DatabaseError`` because the first case surfaces as |
| 110 | + ``InterfaceError``, a sibling of ``DatabaseError`` rather than one of |
| 111 | + its subclasses. |
| 112 | + :raises ArgumentError: When the resolved URL is malformed, or names a dialect |
| 113 | + whose driver is not installed. The engine is built before the wait, so |
| 114 | + this surfaces immediately. |
| 115 | + """ |
| 116 | + manager = SessionManager() |
| 117 | + engine, _ = manager.create_session( |
| 118 | + settings.CELERY.beat_dburi, |
| 119 | + schema=settings.CELERY.beat_schema, |
| 120 | + ) |
| 121 | + try: |
| 122 | + _wait_for_store(engine) |
| 123 | + manager.prepare_models(engine, schema=settings.CELERY.beat_schema) |
| 124 | + finally: |
| 125 | + engine.dispose() |
| 126 | + |
| 127 | + |
| 128 | +def main() -> None: |
| 129 | + """Run the bootstrap, configuring logging for a freshly spawned process. |
| 130 | +
|
| 131 | + Supervisord starts this in a process that has run no ``dictConfig``, and the |
| 132 | + wait's own log lines are the only account an operator gets of why the schema |
| 133 | + step has not finished. A failure is deliberately left to propagate: the |
| 134 | + non-zero exit is what keeps the caller's sentinel unwritten. |
| 135 | +
|
| 136 | + :raises SQLAlchemyError: When the tables cannot be created, or the store |
| 137 | + refuses a connection for a reason other than not being up yet. |
| 138 | + """ |
| 139 | + logging.config.dictConfig(settings.LOGGING_CONFIG) |
| 140 | + bootstrap_beat_schema() |
| 141 | + logger.info("Celery beat schedule tables are present.") |
| 142 | + |
| 143 | + |
| 144 | +if __name__ == "__main__": |
| 145 | + main() |
0 commit comments