fix: PSQL query regressions#3748
Merged
Merged
Conversation
- user.repository: replace MSSQL LIKE character-class with PostgreSQL regex operator in getNextRef; the [0-9] class matched 0 rows on Postgres, causing a null deref on every userData update and mail confirm with account merge - config: set relationLoadStrategy 'query' to avoid PostgreSQL's 1664-column target-list limit when finding deep relation trees (broke GET /v1/transaction/single)
7 tasks
❌ ESLint: 1 errors, 2 warnings |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Kontext
Nach dem MSSQL→PostgreSQL-Cutover (#3620, #3744, #3745) zeigen die PRD-Logs systematische HTTP 500 auf mehreren Endpoints. Diese PR behebt zwei bestätigte Query-Regressionen.
Fixes
1.
getNextRef— MSSQL-LIKE-Zeichenklasseuser.repository.tsfilterte mitLike('%[0-9]-[0-9]%'). Die[0-9]-Zeichenklasse ist MSSQL-LIKE-Syntax; PostgreSQL-LIKEbehandelt[]als Literale → 0 Treffer →findOneliefertnull→Cannot read properties of null (reading 'ref').Betroffen:
PUT /v1/userData/*undGET /v1/auth/mail/confirm(Account-Merge).Fix: PostgreSQL-Regex-Operator
~ '[0-9]-[0-9]'viaRaw().2.
transaction/single— PostgreSQL-1664-Spalten-LimitgetTransaction()lädt einen tiefen Relations-Baum (buyCrypto+6,buyFiat+4,user→userData u.a.). Die JOIN-Strategie erzeugt eine SELECT-Targetlist über ~23 Entities und überschreitet PostgreSQLs Limit von 1664 Spalten (QueryFailedError: target lists can have at most 1664 entries). MSSQL erlaubte mehr.Fix:
relationLoadStrategy: 'query'global in der TypeORM-Config — jede Relation wird als separate Query geladen statt als Riesen-JOIN. Behebt das Limit app-weit, nicht nur an dieser Stelle.Nicht in dieser PR
GET /v1/support/*→relation "support_note" does not exist: fix: support note migration for PSQL #3744 ist bereits aufmain; die Tabelle fehlt auf der PRD-DB. Deployment-/Migrations-Frage, kein Code-Fix.PUT /v1/buyCrypto/*→Converting circular structure to JSON: eigenständiger Serialisierungs-Bug, separat zu untersuchen.Test plan
PUT /v1/userData/{id}für einen User ohnerefmit KYC-Level ≥ 50 →refwird vergeben, kein 500GET /v1/auth/mail/confirmmit Account-Merge → kein 500GET /v1/transaction/single?uid=...→ 200 statttarget lists-FehlerrelationLoadStrategy)