Hallo,
Ich habe ein Problem beim Verschieben von Beiträgen auf meiner selbst gehosteten Instanz (v.3.4.0.beta3-dev).
Ich habe mein Reactions-Plugin überprüft, und es ist auf dem neuesten Stand (siehe 500 Error: There was an error moving posts ).
Gibt es eine empfohlene Lösung für dieses Problem (oder weitere Details zur Quelle)?
Vielen Dank im Voraus,
Marc
Moin
12. Dezember 2024 um 14:15
2
Mustachian Post:
.3.4.0.beta3-dev
Wann hast du das letzte Mal aktualisiert?
Diese Woche gab es zwei Korrekturen. Die letzte wurde gestern zusammengeführt.
main ← pento/fix-moving-posts-to-topic-chronologically
opened 03:01AM - 09 Dec 24 UTC
## ✨ What's This?
When moving posts to an existing topic whilst preserving ch… ronological ordering, the second chunk of posts moved can trigger a PostgreSQL error:
```
PG::UniqueViolation (ERROR: duplicate key value violates unique constraint "post_timings_unique"
DETAIL: Key (topic_id, post_number, user_id)=(36, 29, 1) already exists.
)
lib/mini_sql_multisite_connection.rb:109:in `run'
app/models/post_mover.rb:432:in `copy_shifted_post_timings_from_temp'
app/models/post_mover.rb:118:in `handle_moved_references'
app/models/post_mover.rb:94:in `move_posts_to'
app/models/post_mover.rb:28:in `block in to_topic'
app/models/post_mover.rb:28:in `to_topic'
```
The cause of this error is a little bit silly.
After a post has been moved from a different topic, a moderator post is inserted into the old topic, pointing to where the post has been moved to.
This moderator post is ultimately created using `PostCreator`, which by default, records a 5000ms Post Timing for that newly created post. Because of how Post Timings are tracked, this timing will be inserted into the `post_timings` table with the same `topic_id`, `post_number`, and `user_id` as the moved post used to have before it was moved.
Now, when we proceed to moving the next post, `PostMover.move_post_timings` will look for post timings to move based on whether there's a corresponding entry in the `moved_posts` table. This is where our problem lays: the post that we previously moved has an entry in the `moved_posts` table, but now there's an unexpected entry in `post_timings` that we know doesn't belong to the previously moved post, but it has matching `topic_id`, `post_number`, and `user_id` of the what that moved post used to have, anyway.
To fix this, we can enforce only matching post IDs that are being moved in this run of `PostMover`.
Internal ref t/142010/5
## 👑 Testing
The simplest way to reproduce this error is:
- Create a destination topic.
- Create the first source topic, and add a reply to it.
- Create a second source topic, and add a reply to it.
- Move the reply in the second source topic to the destination topic, remembering to check the “preserve chronological order” option.
- Move the reply in the first source topic to the destination, again checking the “preserve chronological order” option.
main ← pento/fix-moving-first-posts-to-topic-chronologically
opened 03:13AM - 11 Dec 24 UTC
## ✨ What's This?
This is a follow-up to #30176.
When moving multiple firs… t posts to an existing topic whilst preserving chronological ordering, the second move can trigger a PostgreSQL error:
```
PG::UniqueViolation:
ERROR: duplicate key value violates unique constraint "post_timings_unique"
DETAIL: Key (topic_id, post_number, user_id)=(1278, 2, 2261) already exists.
# ./lib/mini_sql_multisite_connection.rb:109:in `run'
# ./app/models/post_mover.rb:478:in `copy_shifted_post_timings_from_temp'
# ./app/models/post_mover.rb:137:in `handle_moved_references'
# ./app/models/post_mover.rb:108:in `move_posts_to'
# ./app/models/post_mover.rb:35:in `block in to_topic'
# ./app/models/post_mover.rb:35:in `to_topic'
# ./app/models/topic.rb:1308:in `move_posts'
```
Additionally, if you move from the same topic to a newer destination: it will fail with this error:
```
PG::CardinalityViolation:
ERROR: ON CONFLICT DO UPDATE command cannot affect row a second time
HINT: Ensure that no rows proposed for insertion within the same command have duplicate constrained values.
# ./lib/mini_sql_multisite_connection.rb:109:in `run'
# ./app/models/post_mover.rb:488:in `copy_first_post_timings'
# ./app/models/post_mover.rb:139:in `handle_moved_references'
# ./app/models/post_mover.rb:108:in `move_posts_to'
# ./app/models/post_mover.rb:35:in `block in to_topic'
# ./app/models/post_mover.rb:35:in `to_topic'
# ./app/models/topic.rb:1308:in `move_posts'
```
Both of these issues can be fixed using the same approach as in #30176: ensuring we only copy post timings for the specific posts that are being moved.
Internal ref t/142010/15
## 👑 Testing
The first error can be reproduced using this method:
- Create two source topics with no replies to either.
- Create a destination topic.
- Move the single post in the second topic to the destination.
- Move the single post in the first topic to the destination.
The second error can be reproduced with this method:
- Create a source topic, and add a reply to it.
- Create a destination topic.
- Move the reply in the source topic to the destination topic, remembering to check the “preserve chronological order” option.
- Move the first post in the source topic to the destination, again checking the “preserve chronological order” option.
2 „Gefällt mir“
Vor ein paar Wochen. Ich habe gerade ein Update durchgeführt, und das hat das Problem behoben
Vielen Dank für die schnelle Unterstützung, das Thema kann geschlossen werden.
2 „Gefällt mir“