[PR #324] [MERGED] Switch OAuth provider reads to PostgreSQL and enable Wix monitoring #289

New issue

Closed

opened 2026-03-02 23:34:59 +03:00 by kerem · 0 comments

kerem commented

2026-03-02 23:34:59 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/AJaySi/ALwrity/pull/324
Author: @AJaySi
Created: 2/9/2026
Status: ✅ Merged
Merged: 2/9/2026
Merged by: @AJaySi

Base: main ← Head: codex/update-provider-services-for-postgresql

📝 Commits (2)

1e7dd68 Move provider token reads to PostgreSQL
e66fbeb Document postgres oauth migration and add comments

📊 Changes

10 files changed (+1312 additions, -616 deletions)

View changed files

📝 backend/routers/bing_oauth.py (+18 -25)
📝 backend/routers/gsc_auth.py (+17 -25)
📝 backend/services/gsc_service.py (+275 -105)
📝 backend/services/integrations/bing_oauth.py (+313 -148)
➕ backend/services/integrations/provider_registry.py (+54 -0)
📝 backend/services/integrations/wix_oauth.py (+219 -96)
📝 backend/services/integrations/wordpress_oauth.py (+218 -104)
📝 backend/services/oauth_token_monitoring_service.py (+44 -81)
📝 backend/services/scheduler/executors/oauth_token_monitoring_executor.py (+84 -32)
➕ docs/oauth_provider_postgres_migration.md (+70 -0)

📄 Description

Motivation

Move provider token reads off local SQLite and into the PostgreSQL SSOT so monitoring and task restoration use the platform registry and central storage (gsc_credentials, bing_oauth_tokens, wordpress_oauth_tokens, wix_oauth_tokens).
Keep existing SQLite writes temporarily for safe rollback/fallback during the migration (dual-write) while making PostgreSQL the primary read path.
Enable backend Wix monitoring by replacing the previous frontend-only _check_wix_token behavior with a backend check against stored tokens.

Description

Added a ProviderRegistry and switched get_connected_platforms to use the registry and provider get_user_token_status APIs rather than reading SQLite files directly, and preserved dual-write behavior for rollback safety (backend/services/integrations/provider_registry.py, backend/services/oauth_token_monitoring_service.py).
Updated provider integration services (GSCService, BingOAuthService, WordPressOAuthService, WixOAuthService) to initialize and read/write PostgreSQL tables (while continuing to write to the existing SQLite tables), and added helper _execute_postgres/table init logic to each service to centralize Postgres access (backend/services/gsc_service.py, backend/services/integrations/bing_oauth.py, backend/services/integrations/wordpress_oauth.py, backend/services/integrations/wix_oauth.py).
Switched the OAuth monitoring executor to use ProviderRegistry for platform service instances and replaced the old frontend-only Wix path with a backend token check in _check_wix_token, enabling Wix monitoring and refresh/expiry handling (backend/services/scheduler/executors/oauth_token_monitoring_executor.py).
Updated OAuth callback routers to source the user_id from the new Postgres-backed results where appropriate and to create platform insights tasks from the Postgres-backed user id when available (backend/routers/gsc_auth.py, backend/routers/bing_oauth.py).

Testing

Automated tests: none executed as part of this change (no CI/test run was performed).
Local validation: code compiled and committed; developers should run integration tests and confirm Postgres env vars PLATFORM_DATABASE_URL / USER_DATA_DATABASE_URL are set before deploying to verify table creation and monitoring task flows.

Codex Task

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/AJaySi/ALwrity/pull/324 **Author:** [@AJaySi](https://github.com/AJaySi) **Created:** 2/9/2026 **Status:** ✅ Merged **Merged:** 2/9/2026 **Merged by:** [@AJaySi](https://github.com/AJaySi) **Base:** `main` ← **Head:** `codex/update-provider-services-for-postgresql` --- ### 📝 Commits (2) - [`1e7dd68`](https://github.com/AJaySi/ALwrity/commit/1e7dd68bf145b57ad2fcf8a724bb1f3e1935875d) Move provider token reads to PostgreSQL - [`e66fbeb`](https://github.com/AJaySi/ALwrity/commit/e66fbeb2525a91a2e3c6f77a711ec7074313eb84) Document postgres oauth migration and add comments ### 📊 Changes **10 files changed** (+1312 additions, -616 deletions) <details> <summary>View changed files</summary> 📝 `backend/routers/bing_oauth.py` (+18 -25) 📝 `backend/routers/gsc_auth.py` (+17 -25) 📝 `backend/services/gsc_service.py` (+275 -105) 📝 `backend/services/integrations/bing_oauth.py` (+313 -148) ➕ `backend/services/integrations/provider_registry.py` (+54 -0) 📝 `backend/services/integrations/wix_oauth.py` (+219 -96) 📝 `backend/services/integrations/wordpress_oauth.py` (+218 -104) 📝 `backend/services/oauth_token_monitoring_service.py` (+44 -81) 📝 `backend/services/scheduler/executors/oauth_token_monitoring_executor.py` (+84 -32) ➕ `docs/oauth_provider_postgres_migration.md` (+70 -0) </details> ### 📄 Description ### Motivation - Move provider token reads off local SQLite and into the PostgreSQL SSOT so monitoring and task restoration use the platform registry and central storage (`gsc_credentials`, `bing_oauth_tokens`, `wordpress_oauth_tokens`, `wix_oauth_tokens`). - Keep existing SQLite writes temporarily for safe rollback/fallback during the migration (dual-write) while making PostgreSQL the primary read path. - Enable backend Wix monitoring by replacing the previous frontend-only `_check_wix_token` behavior with a backend check against stored tokens. ### Description - Added a `ProviderRegistry` and switched `get_connected_platforms` to use the registry and provider `get_user_token_status` APIs rather than reading SQLite files directly, and preserved dual-write behavior for rollback safety (`backend/services/integrations/provider_registry.py`, `backend/services/oauth_token_monitoring_service.py`). - Updated provider integration services (`GSCService`, `BingOAuthService`, `WordPressOAuthService`, `WixOAuthService`) to initialize and read/write PostgreSQL tables (while continuing to write to the existing SQLite tables), and added helper `_execute_postgres`/table init logic to each service to centralize Postgres access (`backend/services/gsc_service.py`, `backend/services/integrations/bing_oauth.py`, `backend/services/integrations/wordpress_oauth.py`, `backend/services/integrations/wix_oauth.py`). - Switched the OAuth monitoring executor to use `ProviderRegistry` for platform service instances and replaced the old frontend-only Wix path with a backend token check in `_check_wix_token`, enabling Wix monitoring and refresh/expiry handling (`backend/services/scheduler/executors/oauth_token_monitoring_executor.py`). - Updated OAuth callback routers to source the `user_id` from the new Postgres-backed results where appropriate and to create platform insights tasks from the Postgres-backed user id when available (`backend/routers/gsc_auth.py`, `backend/routers/bing_oauth.py`). ### Testing - Automated tests: none executed as part of this change (no CI/test run was performed). - Local validation: code compiled and committed; developers should run integration tests and confirm Postgres env vars `PLATFORM_DATABASE_URL` / `USER_DATA_DATABASE_URL` are set before deploying to verify table creation and monitoring task flows. ------ [Codex Task](https://chatgpt.com/codex/tasks/task_e_69897ff78304832887163ce1d987f6a6) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem

2026-03-02 23:34:59 +03:00

closed this issue
added the
pull-request
label

kerem referenced this issue

2026-03-13 20:49:35 +03:00

[GH-ISSUE #289] [FEATURE] Clerk Subscription model and billing #540

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/ALwrity#289

No description provided.

Rows
Columns