Hey there,
I’m having an issue moving posts on my self-hosted instance (v.3.4.0.beta3-dev)
I checked my reactions plugin, and it’s up-to-date (seeing 500 Error: There was an error moving posts ).
Is there any recommended fix for such issue (or more details on the source)?
Thanks in advance,
Marc
Moin
12. Dezember 2024 um 14:15
2
Mustachian Post:
.3.4.0.beta3-dev
When did you last update?
There were two fixes this week. The last one was merged yesterday.
discourse:main
← discourse: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.
discourse:main
← discourse: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“
Few weeks back. I just updated, and it fixed the issue
Thanks for the fast support, topic can be closed.
2 „Gefällt mir“