SQL-Fehler mit `screened_ip_addresses` (API wirft 500)

[pnoeric (Eric)]

Hallo Freunde,

die API gibt mir einen Fehler 500 zurück, wenn ich versuche, einen neuen Beitrag in einem bestehenden Thema zu erstellen. In den Logs sehe ich:

ActiveRecord::StatementInvalid (PG::InvalidTextRepresentation: ERROR:  ungültige Eingabesyntax für Typ inet: ""
LINE 1: ..._addresses".* FROM "screened_ip_addresses" WHERE ('' <<= ip_...
                                                             ^
)
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-mini-profiler-2.0.1/lib/patches/db/pg.rb:69:in `exec_params'

Fehler beim Behandeln der Ausnahme in der Ausnahme-App-Middleware: PG::InvalidTextRepresentation: ERROR:  ungültige Eingabesyntax für Typ inet: ""
LINE 1: ..._addresses".* FROM "screened_ip_addresses" WHERE ('' <<= ip_...
                                                             ^

Hier ist meine Liste der geprüften IPs – zusätzlich zum Screenshot unten habe ich auch die IP der Maschine freigegeben, die die API aufruft. (Ich verwende einen systemweiten API-Schlüssel, um alte Themen/Nachrichten aus meiner alten Forum-Software massenhaft zu importieren.)

Nur zum Spaß habe ich die API auch nach der Liste der geprüften IPs gefragt … gleiche Ergebnisse. (https://mydiscourse.com/admin/logs/screened_ip_addresses.json)

Ich bin mir nicht sicher, was ich noch überprüfen soll.

Weiß jemand:

1. Was verursacht diesen Fehler, und
2. Wie kann ich ihn jetzt beheben und verhindern, dass er in Zukunft wieder auftritt?

Hilfe

Danke!

[pnoeric (Eric)]

Oder geht es hier eher um ein anderes SQL, das versucht, in diese Tabelle einzufügen?

[blake (Blake Erickson)]

Kannst du bitte den Code posten, den du für die API-Anfrage verwendest, nachdem du die Zugangsdaten entfernt hast? So können wir sehen, wie du die API-Anfrage durchführst.

[pnoeric (Eric)]

Hey @blake, danke für die Antwort. Um ganz sicherzugehen, dass es nicht an meinem Code lag, habe ich den grundlegenden API-Aufruf in Insomnia (ähnlich wie Postman, aber meiner Meinung nach einfacher/leichter) zusammengestellt. Leider das gleiche Ergebnis, aber jetzt ist es zumindest sehr klar:

Hier ist der Aufruf, den ich zum Erstellen eines neuen Beitrags vorbereitet habe (ich habe die Einstellung „Mindestanzahl von Wörtern in Beiträgen

[pnoeric (Eric)]

Also, so habe ich den Bug umgangen… Ich habe angefangen zu experimentieren:

1. Ich habe den Benutzer in meinem API-Aufruf auf ‘system’ geändert, und das hat funktioniert.
2. Also dachte ich mir so: Hmm, und ich habe den Benutzer auf einen dritten Benutzer geändert, den ich noch nicht ausprobiert hatte. Das funktionierte ebenfalls.
3. Dann habe ich den Benutzer wieder auf den ursprünglichen Benutzernamen geändert, was bedeutet, dass ich exakt denselben API-Aufruf wiederholt hätte, der zuvor einen 500-Fehler ausgelöst hatte. Doch diesmal funktionierte es.

Sollte das Problem erneut auftreten, werde ich versuchen, herauszufinden, wie ich es zuverlässig reproduzieren kann. In der Zwischenzeit könnte vielleicht jemand, der den Discourse-Code besser kennt als ich , einen Blick darauf werfen und sicherstellen, dass keine offensichtlichen Fehler aufspringen.

[pnoeric (Eric)]

Hmmm, hier läuft definitiv etwas Seltsames ab. Ich habe mein Skript erneut gestartet, und es beginnt wieder, Themen im Bulk zu erstellen und Nachrichten zu posten – und diesmal, wieder mit einem anderen Benutzer, erhalte ich den 500er Fehler.

Ich überprüfe diesen Benutzernamen in Insomnia und teste die API… wie erwartet, 500er Fehler. Ich wechsle zu ‘system’, und es funktioniert… dann gehe ich zurück zum ursprünglichen Benutzernamen, und es schlägt erneut mit einem 500er Fehler fehl!

Der Benutzer, der den 500er Fehler auslöst (und alle meine importierten Benutzer außer ‘system’), hat die Vertrauensstufe TL1. Ich habe die Limits so angepasst, dass TL1 posten darf und

Das fühlt sich definitiv nach etwas an, das mit Rate Limiting zu tun hat, oder? Ich würde vermuten, dass Nginx oder etwas anderes stromaufwärts den 500er Fehler verursacht, aber ich habe alle Rate-Limiting-Einstellungen in Nginx entfernt, und der 500er Fehler erscheint in den Fehlerprotokollen eindeutig als dieser SQL-Fehler.

Mir ist aufgefallen, dass der SQL-Fehler bei einer Spalte, die auf eine IP-Adresse verweist, abstürzt. Könnte es etwas Seltsames geben, wie Rate Limiting funktioniert, das dieses Problem verursachen könnte? Ich habe versucht, mich über ein VPN einzuloggen (um meine IP zu ändern), aber ich erhalte weiterhin den 500er Fehler.

In der Zwischenzeit sehe ich, dass das Problem in rack-mini-profiler liegt, was nicht notwendig ist. Mal sehen, ob ich das abschalten kann und ob das das Problem behebt. … Nein. Jetzt sehe ich den Mini-Profiler auf meinem Admin-Konto nicht mehr, aber ich erhalte weiterhin denselben HTTP-500-Fehler mit denselben Fehlern im Fehlerprotokoll

Update: Durch die Änderung des Benutzers auf TL3 scheint das Problem zu verschwinden. Beim Zurückwechseln auf TL1 tritt es erneut auf. Ich teste diese Theorie gerade… nein. Manchmal funktioniert das, aber manchmal scheint der Benutzer, selbst wenn ich die TL des Benutzers manuell bearbeite, „stecken zu bleiben".

@blake oder jemand anderes aus @staff… Hilfe! Was bleibt noch zu versuchen? Gibt es etwas, das ich hier vollständig zurücksetzen (im Zusammenhang mit dem Code, der den Fehler auslöst) und auf Werkseinstellungen zurücksetzen kann?

[codinghorror (Jeff Atwood)]

Nach dem Stack-Trace scheint es sich für mich um ein mögliches Netzwerkproblem zu handeln, da manchmal aus irgendeinem Grund keine IP-Adresse für den Benutzer angezeigt wird. Oder gibt es fehlerhafte Datenbankdaten in Admin, Logs oder den gescreenten IP-Adressen?

[supermathie (Michael Brown)]

Zustimmung – <<= bedeutet „LHS enthalten in RHS“, also scheint eine fehlerhafte/leere IP-Adresse in die App zu gelangen.

(Ich bin neugierig, wie es sein kann, dass der App KEINE IP-Adresse zur Verfügung steht; meine einzige Vermutung ist, dass die Anfrage über einen Unix-Socket ohne Forwarded-IP-Header kommt)

[pnoeric (Eric)]

@codinghorror

Basierend auf dem Stack-Trace sieht es für mich nach einem möglichen Netzwerkproblem aus, da manchmal scheinbar keine IP-Adresse für den Benutzer erfasst wird. Oder hast du fehlerhafte Daten in der Datenbank (Admin, Logs, gefilterte IP-Adressen)?

Stimmt, aber ich verstehe nicht, warum die IP manchmal vorhanden und manchmal nicht vorhanden ist. In meinem Import-Skript erhalte ich diesen 500-Fehler nach mindestens 5–7 erfolgreichen API-Aufrufen davor. Deshalb vermute ich, dass es sich um beschädigte Daten in der Datenbank handelt.

@supermathie

Stimmt – <<= bedeutet „LHS enthalten in RHS“, also scheint eine fehlerhafte/leere IP-Adresse an die Anwendung zu gelangen.

(Ich bin neugierig, wie es sein kann, dass der App überhaupt keine IP-Adresse zur Verfügung steht; meine einzige Vermutung ist, dass die Anfrage über einen Unix-Socket kommt, ohne dass ein Header mit weitergeleiteter IP-Information vorhanden ist)

Ja, das ist seltsam. Aber gleichzeitig scheitert der Aufruf, wenn ich einen „fehlerhaften

[blake (Blake Erickson)]

@pnoeric

Kann mir jemand einfache Ruby-Befehlszeilenbefehle nennen, mit denen ich Datenbanktabellen zurücksetzen oder leeren kann, falls sie beschädigt sein sollten?

Ich glaube nicht, dass mit deiner Datenbank etwas nicht stimmt, denn der Fehler prüft, ob in der Tabelle der gefilterten IP-Adressen eine leere IP-Adresse vorhanden ist, nicht ob in deiner Datenbank leere IP-Adressen existieren.

Das Interessante ist jedoch, dass dieser Code die Existenz einer IP-Adresse prüft, bevor er die SQL-Anfrage ausführt, die den 500er-Fehler verursacht.

Könntest du beschreiben, wie deine Discourse-Instanz eingerichtet ist? Stammt sie aus einem Import? Bist du auf der neuesten Version? Wie viel RAM hat sie? Hast du dich an diese Anleitung gehalten?

Kannst du diese Site-Einstellung überprüfen: max new accounts per registration ip? Ich bin mir nicht sicher, ob dies in diesem Fall relevant ist, aber vielleicht verursacht es ein Problem.

Könntest du in deinem Bulk-Skript die Geschwindigkeit verringern und zwischen den Anfragen eine 1-Sekunden-Pause einfügen, um zu sehen, ob das einen Unterschied macht?

Was ist der Zweck dieser API-Aufrufe? Handelt es sich um ein einmaliges Skript zum Erstellen von importierten Benutzern und Beiträgen? In diesem Fall wäre vielleicht ein Import-Skript, das direkt auf dem Server läuft und keine API-Aufrufe tätigt, besser geeignet?

Entschuldige die vielen Fragen, aber wir sind diesem Problem noch nie begegnet, und der Code rund um screened_ip_addresses wurde schon lange nicht mehr aktualisiert. Ich sage nicht, dass es keinen Fehler im Codebase gibt, aber nach einem kurzen Blick fällt mir im Moment nichts Besonderes auf.

[pnoeric (Eric)]

@blake

Könntest du beschreiben, wie deine Discourse-Instanz eingerichtet ist? Stammt sie von einem Import? Bist du auf der neuesten Version? Wie viel RAM hat sie? Hast du dich an diesen Leitfaden gehalten?

Klar – es läuft komplett über Docker auf Digital Ocean. Ich habe diesen hervorragenden Leitfaden bis ins kleinste Detail befolgt.

@blake

Könntest du diese Site-Einstellung prüfen: max new accounts per registration ip? Ich bin mir nicht sicher, ob das in diesem Fall relevant ist, aber vielleicht verursacht es ein Problem.

Klar, ich habe diese Einstellung gerade von der Standardzahl 3 auf 99999 geändert. Keine Veränderung, immer noch der 500-Fehler.

@blake

In deinem Bulk-Skript könntest du es verlangsamen und eine 1-Sekunden-Pause zwischen den Anfragen einfügen, um zu sehen, ob das einen Unterschied macht?

Habe ich versucht, kein Unterschied. Beachte, dass ich den 500-Fehler auch mit NUR einem „schlechten

[blake (Blake Erickson)]

Was passiert, wenn Sie SSO deaktivieren?

[pnoeric (Eric)]

Kein Unterschied, es wird weiterhin der 500-Fehler ausgelöst.

[riking (Kane York)]

Eine weitere Idee: Ist es möglich, dass jedes Konto, für das es funktioniert hat, ein Admin ist? Ich weiß, dass einige Anwendungsbereichs-Ratenbegrenzungen für Admins umgangen werden.

Im Allgemeinen ist es jedoch viel einfacher, einfach ein Import-Skript zu schreiben. Dieses gesamte Thema zeigt, wie viel „viel

[pnoeric (Eric)]

@riking

Eine weitere Idee: Ist es möglich, dass bei jedem Konto, für das es funktioniert hat, ein Administratoraccount vorliegt? Ich weiß, dass einige Anwendungsratenbegrenzungen für Administratoren umgangen werden.

Hmm, ich dachte, ich hätte da schon etwas gefunden… Mein getesteter „vergifteter