Skalare Tags-Parameter in der Prüfungsqueue verursacht HTTP 500 bei Genehmigung

Beitragen Fehler
1

Die Genehmigung eines in der Warteschlange befindlichen Themas auf unserer selbst gehosteten Site schlug mit HTTP 500 fehl, da der Datensatz in der Warteschlange payload.tags = "macos" (eine Zeichenkette) enthielt. Der fehlerhafte Wert war bereits von POST /posts akzeptiert worden.

Ich verstehe, dass Clients ein Array von Tags senden sollten. Das Problem, das ich hier melde, ist, dass ein ungültiger Skalare Wert in die Review-Warteschlange aufgenommen werden kann und erst später fehlschlägt, wenn ein Moderator den Beitrag genehmigt.

Version: 2026.10.0-latest, Commit 3f2bf92368c78a7fa9a755f3d046adf35dd4459b.

Belege aus dem Vorfall

Der Beitrag erforderte eine Genehmigung aufgrund von approve_post_count.

Um 2026-10-22 13:37:52 UTC enthielten die ursprünglichen Rails-Anforderungsparameter bereits:

"tags" => "macos"

Die Anforderung war POST /posts und das entsprechende Zugriffsprotokoll protokollierte HTTP 200. Die übergebenen Parameternamen waren title, raw, category und tags.

Das Lesen des ausstehenden prüfbaren Elements bestätigte Folgendes:

{
  "type": "ReviewableQueuedPost",
  "status": 0,
  "version": 0,
  "topic_id": null,
  "payload": {
    "tags": "macos"
  }
}

Dies ist eine Auszug der relevanten Felder, wobei Titel, Inhalt und Benutzerinformationen weggelassen wurden. Die Review-Benutzeroberfläche zeigte das Tag als fünf separate Buchstaben an: m, a, c, o, s.

Das Klicken auf „Genehmigen“ erzeugte diese Ausnahme (fünf gruppierte Vorkommnisse in den Logs):

NoMethodError (undefined method '-' for an instance of String)
lib/discourse_tagging.rb:932:in 'DiscourseTagging.tags_for_saving'
lib/discourse_tagging.rb:43:in 'DiscourseTagging.tag_topic_by_names'
lib/discourse_tagging.rb:30:in 'DiscourseTagging.tag_topic'
lib/topic_creator.rb:228:in 'TopicCreator#setup_tags'
lib/topic_creator.rb:60:in 'TopicCreator#create'
lib/post_creator.rb:519:in 'PostCreator#create_topic'
lib/post_creator.rb:209:in 'block in PostCreator#create'
lib/post_creator.rb:419:in 'block in PostCreator#transaction'
lib/post_creator.rb:419:in 'PostCreator#transaction'
lib/post_creator.rb:207:in 'PostCreator#create'
app/models/reviewable_queued_post.rb:110:in 'ReviewableQueuedPost#perform_approve_post'
app/models/reviewable.rb:433:in 'Kernel#public_send'
app/models/reviewable.rb:433:in 'block in Reviewable#perform'
app/models/reviewable.rb:431:in 'Reviewable#perform'
app/controllers/reviewables_controller.rb:287:in 'ReviewablesController#perform'

Relevanter Code

Dies sind die Code-Pfade, die im laufenden Container beim oben genannten Commit überprüft wurden:

  • PostsController#create_params ruft params.permit(tags: %i[id name]) auf, verwendet die zurückgegebenen gefilterten Parameter jedoch nicht. Es weist dann den ursprünglichen Wert mit result[f] = params[f] zu.
  • NewPostManager#enqueue kopiert @args[:tags] direkt in den Payload des prüfbaren Elements.
  • ReviewableQueuedPost#create_options konvertiert Tags nur, wenn der Wert bereits ein Array ist, und lässt eine skalare Zeichenkette unverändert.
  • DiscourseTagging.tags_for_saving wertet dann tags_arg - tag_names aus, wenn der genehmigende Benutzer Tags erstellen kann, was bei einer Zeichenkette zu einem Fehler führt.

Erwartetes Verhalten

Einen skalaren tags-Parameter mit einem klaren Validierungsfehler ablehnen, bevor das prüfbare Element erstellt wird, oder ihn normalisieren, falls dies das beabsichtigte Kompatibilitätsverhalten ist. Ein vorhandenes fehlerhaftes prüfbares Element sollte auch angemessen fehlschlagen, anstatt während der Moderation einen unbehandelten 500-Fehler zu verursachen.

Workaround und Grenzen dieses Berichts

Das Bearbeiten des prüfbaren Elements, das Entfernen des alten Tags, die Auswahl des vorhandenen macos-Tags und das Speichern änderten payload.tags in ein Array von Tag-Objekten. Das erneute Laden bestätigte Version 1, weiterhin ausstehend, und die Benutzeroberfläche zeigte wieder ein Tag an. Ich habe die Genehmigung nach dieser Änderung nicht erneut versucht.

Der Client des ursprünglichen Absenders ist unbekannt. Dieser Bericht stellt nicht fest, dass der native Composer skalare Tags erzeugt. Er basiert auf der tatsächlichen Anfrage, dem gespeicherten prüfbaren Element, der Ausnahme und dem inspizierten Code; ich habe es nicht separat auf einer sauberen Installation reproduziert.

Für eine Entwicklungsreproduktion ist der zu testende Pfad: Genehmigung für einen Beitrag eines Nicht-Mitglieds verlangen, POST /posts mit einem skalaren tags: "macos" und anderen gültigen Feldern absenden und den resultierenden gepufferten Beitrag dann als Administrator genehmigen.

Es gibt eine ältere API-Diskussion mit derselben String-Subtraktionsausnahme. Dieser Bericht konzentriert sich darauf, dass der ungültige Wert in die Review-Warteschlange aufgenommen wird und die spätere Genehmigung stört.

2

ich bin ehrlich gesagt nicht sicher, woher das kommt, aber hier ist ein Fix, um es zu verbannen.

1 „Gefällt mir“