Outbox: record logs #1197
Outbox: record logs #1197
Conversation
This is a simple rewrite of the current dispatcher system, to use the Outbox instead of the Scheduler. This is a first draft and will be improved over time, to better handle: * Re-tries * Errors * Logging * Batch processing
mattwiebe
added
the
Skip Changelog
|
@mattwiebe @pfefferle What do we want to do with the data we log? Is it meant for site owners or us? Maybe we could start with |
This is a simple rewrite of the current dispatcher system, to use the Outbox instead of the Scheduler. This is a first draft and will be improved over time, to better handle: * Re-tries * Errors * Logging * Batch processing
Co-authored-by: Konstantin Obenland <[email protected]>
Co-authored-by: Konstantin Obenland <[email protected]>
Co-authored-by: Konstantin Obenland <[email protected]>
Co-authored-by: Konstantin Obenland <[email protected]>
obenland
force-pushed
the
update/dispatcher
branch
from
f9a51cf to
70266cf
Compare
A few use-cases for site owners:
But also for us, give the ability to, say, export a debug log of failed requests (sanitized of any PII) when getting support would give us a huge advantage over today.
That seems like a great idea! I was initially thinking of integrating it into an Outbox post_type listing as a column. |
includes/class-dispatcher.php
Outdated
| @@ -104,8 +104,24 @@ private static function send_activity_to_followers( $activity, $actor_id, $outbo | |||
|
|
|||
| $json = $activity->to_json(); | |||
|
|
|||
| // We will store the json as generated by the transformer, even though it 's also in plaintext in $outbox_item->post_content | |||
| // This will also allow us to keep the logs below leaner. | |||
| \add_post_meta( $outbox_item->ID, 'activitypub_sent_json', $json ); | |||
There was a problem hiding this comment.
why do we need this information?
There was a problem hiding this comment.
Coming back to it, I was just thinking of all of the places I would want to possibly error_log while debugging this code. And this was one. But since we store it in the outbox content anyway, it's definitely superfluous and I'll remove it.
includes/class-dispatcher.php
Outdated
| // This will also allow us to keep the logs below leaner. | ||
| \add_post_meta( $outbox_item->ID, 'activitypub_sent_json', $json ); | ||
| // This will allow error checking later, that all inboxes have been sent. | ||
| \add_post_meta( $outbox_item->ID, 'activitypub_sent_inboxes', $inboxes, true ); |
There was a problem hiding this comment.
shouldn't we simply keep a list of inboxes that bounce? this is a lot of data we store per Outbox Activity!?!
There was a problem hiding this comment.
I wanted a fully debuggable picture of what happens, given that the list of inboxes POSTed to for any given outbox activity will be somewhat dynamically generated. At the same time I was envisioning using it as a basis for rolling batching, which I did not get to.
But since we're not doing batching yet either, and all of the inboxes are stored in the logs below, we don't need it right now.
We don't explicitly have to merge this, since we're already two levels deep on a feature branch, but this is the idea.
We can build on this with CLI and in the Outbox post listing, including retry functionality, and "copy to clipboard" so users can submit that with bug reports.