You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a Delete activity is POSTed to the inbox of a hatsu server, it emits an error 501 with a body along the lines of
{"error":"Failed to parse incoming activity with id <blah>#delete: data did not match any variant of untagged enum UserInboxActivities at line 1 column 804","error_id":"0195ae77-0934-7ea2-851d-d77e61e3175e"}
The hatsu log says something along the lines of
Mar 19 13:01:13 x.uvok.de start.sh[1348]: 2025-03-19T13:01:13.444531Z INFO tower_http::trace::on_response: finished processing request, latency: 1 ms, status: 500
Mar 19 13:01:13 x.uvok.de start.sh[1348]: at /home/uvok/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tower-http-0.5.2/src/trace/on_response.rs:114
Mar 19 13:01:13 x.uvok.de start.sh[1348]: in tower_http::trace::make_span::request with method: POST, uri: /users/blog.uvokchee.de/inbox, version: HTTP/1.0
Mar 19 13:01:13 x.uvok.de start.sh[1348]: 2025-03-19T13:01:13.444614Z ERROR tower_http::trace::on_failure: response failed, classification: Status code: 500 Internal Server Error, latency: 1 ms
Mar 19 13:01:13 x.uvok.de start.sh[1348]: at /home/uvok/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tower-http-0.5.2/src/trace/on_failure.rs:93
Mar 19 13:01:13 x.uvok.de start.sh[1348]: in tower_http::trace::make_span::request with method: POST, uri: /users/blog.uvokchee.de/inbox, version: HTTP/1.0
Is this intended? I don't think hatsu can actually handle the delete activity, but can it be "swallowed" or maybe replied with "operation not supported"?
I haven't been able to figure out how exactly hatsu, or rather, the activitypub_federation crate, maps the type of the JSON to a handler, I only found I have to start (or rather, finish) at crates/apub/src/activities/activity_lists.rs and probably "implement my way backwards" from there. Still, I'm completely clueless how the actual "mapping" works. It seems "serde" is involved in this.
The text was updated successfully, but these errors were encountered:
I haven't been able to figure out how exactly hatsu, or rather, the activitypub_federation crate, maps the type of the JSON to a handler, I only found I have to start (or rather, finish) at crates/apub/src/activities/activity_lists.rs and probably "implement my way backwards" from there. Still, I'm completely clueless how the actual "mapping" works. It seems "serde" is involved in this.
Yes, the imported struct in this file describes the corresponding JSON format.
Hatsu does not currently support Delete activities. Will it cause the process to crash? If not, you can safely ignore this error.
No, it doesn't. I was trying to figure out an unrelated problem (a reply to my AP status not being saved into in database for some reason) and was confused by the amount of 50x errors in the log.
When a Delete activity is POSTed to the inbox of a hatsu server, it emits an error 501 with a body along the lines of
The hatsu log says something along the lines of
Is this intended? I don't think hatsu can actually handle the delete activity, but can it be "swallowed" or maybe replied with "operation not supported"?
I haven't been able to figure out how exactly hatsu, or rather, the activitypub_federation crate, maps the type of the JSON to a handler, I only found I have to start (or rather, finish) at
crates/apub/src/activities/activity_lists.rs
and probably "implement my way backwards" from there. Still, I'm completely clueless how the actual "mapping" works. It seems "serde" is involved in this.The text was updated successfully, but these errors were encountered: