Received Video objects from PeerTube are not understood #892
Labels
No labels
approved, awaiting change
broken setup
bug
cannot reproduce
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs change/feedback
needs docs
needs tests
not a bug
not our bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
AkkomaGang/akkoma#892
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Forwarded from https://meta.akkoma.dev/t/errors-in-log/841
Your setup
OTP
Extra details
(unknown)
Version
3.15.2
PostgreSQL version
(unknown)
Describe the issue and provide relevant logs
It seems there’s an interop issue with PeerTube with us failing to understand the
Videoobjects they send, specificallytagandattachment. NoteAudioandVideoobjects are processed by a different validator than the more commonNote,Article, etc.And here’s the failing object as shown when fetched (note though, while uncommon some implementations, like bridgy, show objects differently on fetch and proactive delivery)
Full object JSON (long)
Severity
I can manage
Have you searched for this issue?
I met the same problem with
tagfield in theQuestiontype objects and I took some time investigating and fixed it. Just a disclaimer that I have zero experience with Elixir so I might be wrong with my vocabulary.Starting from the error message:
Basically, it means that the
tagfield doesn't pass the validation as an embedded schema of the containing object, which, in OP's case,AudioVideoValidatorand in my case,QuestionValidator. In more details, when the validator is looking at thetagfield, it expects it to be an array of maps.If you check the original object json by accessing it through the url in the id, it indeed satisfies the type requirement. However, if dumping the object from the objects table in the database, there are additional string-typed elements in the tag array, which come from:
# Insert copy of hashtags as strings for the non-hashtag table indexingtag = (object["tag"] || []) ++ Object.hashtags(%Object{data: object})object = Map.put(object, "tag", tag)In the general note validator, there is a fix for this:
defp fix_tag(%{"tag" => tag} = data) when is_list(tag) doMap.put(data, "tag", Enum.filter(tag, &is_map/1))enddefp fix_tag(%{"tag" => tag} = data) when is_map(tag), do: Map.put(data, "tag", [tag])defp fix_tag(data), do: Map.drop(data, ["tag"])This filters out the string-typed elements when reading the tags from the db and just keeps the maps. And we lack this logic in other special object validators.
As a test, I copied the
fix_tagmethods intoQuestionValidatorand the problem is solved. This is not the cleanest solution though. I believe we should move the fix into the common_fixes.ex. Maybe not only the tag fix, but also other fixes in the article_note_page_validator.ex.