hongminhee OP , 2 days ago

When there is no queue, if the process fails, the inbox can just respond with a 500 server error and the sender will resend it.

But with a queue, by the time the inbox responds, it doesn't know if the process will fail because it hasn't run yet. So the sender won't retry whether it fails or not.

So, should it have its own retry logic when there is a queue?

#Fedify #fedidev #ActivityPub

thisismissem , 2 days ago

@hongminhee see: https://socialhub.activitypub.rocks/t/report-errors-in-server-processing/3006

hongminhee OP , 2 days ago

@thisismissem The link you showed was very helpful, thank you!

thisismissem , 2 days ago

@hongminhee yeah, basically there's a lot of undefined's here, iirc. I know @hrefna has done a lot of research around queues for AP, and also maybe @helge

hrefna , 2 days ago

@thisismissem

I think of this from a distributed systems standpoint, because none of this is defined in AP.

With a distributed system when you respond successfully to a message you're saying "I've got it from here" and you are responsible for handling it.

This means that if the error is retryable you'll need to manage the retry logic.

What we don't have is a way of asynchronously reporting non retryable errors, there are a few proposals there but nothing adopted.

@hongminhee @helge

hrefna , 2 days ago

@thisismissem

This is part of what makes distributed systems so much more complex than non-distributed systems: once you have done the 200/202 response you are then responsible for the handling and if you haven't communicated back a way for them to find out what happened to it you can't expect them to do anything differently unless it is part of a negotiated protocol.

Trying to solve this is ultimately how we get things like the FLP result and the PACELC theorem.

@hongminhee @helge

KevinMarks , 2 days ago

@hrefna @thisismissem @hongminhee @helge does it not support a 201 response with a status url? That's the pattern used elsewhere for this

hrefna , 2 days ago

@KevinMarks

Nope! That behavior is specified in C2S interactions—where the server returns once it has actually created the object and returns the id of the new object (so not a status URI, but something that you can check nonetheless)—but there's no such specification in S2S interactions (where the spec says basically nothing about return codes).

@thisismissem @hongminhee @helge

hrefna , 2 days ago

@KevinMarks

Both Helge and I have written proposals around this at different points and we've talked about it, but there's nothing in the spec or that would be easy to get widespread adoption on.

@thisismissem @hongminhee @helge

hongminhee OP , 2 days ago

@hrefna Thank you for your kind and detailed answer, it was very helpful!

KevinMarks , 2 days ago

@hrefna @thisismissem @hongminhee @helge that does seem like an underspecified area. Webmention does define a 201 status response, for example.