ProfileResponse schema's default_qr_logo literal was inherited from
xmrcheckout: Literal["monero", "none", "custom"]. The DB column
(models.py) defaults to "wownero" and main.py's migration backfills
NULL → ... but the backfill also wrote "monero", contradicting the
column default.
End result: new users got default_qr_logo="wownero" (from the
column default), but GET /api/core/profile blew up with a Pydantic
ResponseValidationError on serialization because "wownero" isn't in
the literal. UI showed "Unavailable" for both Store ID and Primary
Address because the entire profile response 500'd, leaving
profileData null on the dashboard. API key + webhook secret rendered
fine because those come from cookies, not profileData.
Fix:
- schemas.py: QrLogoMode now Literal["wownero", "monero", "none",
"custom"] (keep "monero" for backward compat with any rows from
before the migration ran)
- schemas.py: ProfileResponse.default_qr_logo default → "wownero"
- main.py: backfill UPDATE → 'wownero' (was 'monero'); migration
column DEFAULT already correct as 'wownero'
- ui/dashboard/page.tsx: TS type for default_qr_logo widened to
include "wownero"; fallback default → "wownero"
- ui/dashboard/actions.ts: DefaultQrLogoState.logo type widened;
validation in updateDefaultQrLogo + initialMetadataPayload now
accepts "wownero"
Suchshop didn't hit this because their wowcheckout user row was
created back when this UI path wasn't being used (they were
provisioned via direct SQL/API). The new shop.wowne.ro merchant
created via the UI today triggered the column default → exposed
the schema mismatch.
Ports xmrcheckout upstream features (7 commits since 655d037):
- SystemStatus model for reconciler heartbeat tracking
- Monero connectivity caching in system status
- Health status endpoints in routes
- Hardened reconciler status updates with SQLAlchemyError handling
- Status schema additions
Adapted for Wownero: 3-decimal precision (0.001 WOW) in amount rounding.
jwinterm