The realtimeLogger registry was a ~40-line copy of logger; extract the
DSN -> adapter -> Logger construction into one $createLogger closure used by
both. realtimeLogger now just resolves _APP_LOGGING_CONFIG_REALTIME (falling
back to _APP_LOGGING_CONFIG), skips Sentry — those errors go out as spans via
app/init/realtime/span.php — and delegates the rest. Cross-referenced the two
"sentry" conditions in both files. No behavior change (legacy ;-delimited
config no longer crashes the realtime registry; it disables logging like the
main one).
Move the Realtime Sentry span exporter registration out of app/realtime.php
into app/init/realtime/span.php (mirrors app/init/span.php / app/init/realtime/
connection.php), and split the now-80-line logError() into recordRealtimeErrorSpan()
(span path) and pushRealtimeErrorLog() (legacy utopia/logger path, non-Sentry
providers only), leaving logError() a small orchestrator. No behavior change.
Realtime errors are now recorded onto a span and shipped to a Sentry
project configured via _APP_LOGGING_CONFIG_REALTIME (falls back to
_APP_LOGGING_CONFIG). The Sentry span exporter is registered in
app/realtime.php so it does not affect the HTTP/worker/CLI span
exporters. logError() attaches the error to the active span, or opens a
short-lived realtime.error span for call sites without one (pub/sub
subscriber, onStart, the Swoole error handler), and keeps the legacy
utopia/logger push only for non-Sentry providers; the realtimeLogger
registry now returns null when the provider is Sentry to avoid
double-reporting. Documents _APP_LOGGING_CONFIG_REALTIME.
After family=m7 was removed from the default e2e_service runner in #12274,
TablesDB inherits the bare 4cpu runner with no instance-family pinning. Under
paratest_processes: 3 the databases worker can't create attributes fast enough
for the polling loop, producing "Expected 'available', Actual 'processing'"
flakes across unrelated PRs. Match the Databases service override to give
TablesDB its own 8cpu runner.
Event::generateEvents() rejects the pattern 'project.delete' because
it parses 'delete' as a resource that must be present in route params.
The pre-migration route did not declare an event label, so functions
and webhooks were never triggered on project deletion. Restore that
behavior by removing the label.
The migrations worker (Appwrite→Appwrite migrations + CSV/JSON imports
& exports) reads `_APP_MIGRATION_HOST` to call back into this instance's
API. `_APP_MIGRATION_HOST` was introduced in #11229 (1.8.x / 1.9.x) but
was never added to `app/config/variables.php`, so `appwrite install` /
`appwrite upgrade` never write it into the generated `.env`. With the
var unset, the migrations worker fails — on a fresh self-hosted install
the first export hangs with no error (#11853). (Contributors and CI
don't hit it because the repo's hand-maintained `.env` already has
`_APP_MIGRATION_HOST=appwrite`; only the *installer-generated* `.env` is
missing it.)
Add `_APP_MIGRATION_HOST` to `app/config/variables.php` with default
`appwrite` — the API service name in the standard Docker Compose setup,
which is what the repo's own `.env` and the cloud Helm charts already
use, and what the migration endpoint was hardcoded to before #11229.
`appwrite install` and `appwrite upgrade` now write it into the
generated `.env`, so fresh installs and upgrades have it set and the
migration/import/export flows work.
Scope: this PR fixes the install & upgrade paths only — it deliberately
doesn't change the worker code.
Fixes#11853
CI lacks _APP_MESSAGE_PUSH_TEST_DSN, so new DSN(null) threw a TypeError
before the existing skip guard could run. Match the pattern used by
testSendPushNotification: gate on the env var first, then construct the DSN.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>