Btw, the best decision I made while implementing for was make a model that stores 1) the payload received and 2) whether it was processed successfully.

This allows filtering down on the payloads received without needing to grep logs while testing in the real world. Since AP isn't exactly a strict protocol, being more of a framework, it's important to easily see the unrecognized payloads sent by real nodes with as little effort as possible.

@hypolite Maybe I should have clarified. When talking about "a model" I also meant "a Django admin page", since that pretty much gets generated automatically.

@jaywink I got it. There is an admin page in Friendica to get the source message for a given item but not for dropped messages.

@hypolite 👍 yeah in this case it's the dropped messages I'm interested in as the point is to ensure they're not dropped :)

@hypolite I mean my original post was a bit of a "what I should have done right at the beginning when starting socialhome". Ie log all federation messages and allow looking at those that are not recognized. Would have saved so much log grepping time.

@hypolite When I started Socialhome, the Diaspora protocol wasn't exactly documented... And neither is the way AP is implemented these days.

@jaywink You're absolutely right, it's just that @heluecht absolutely love grepping log files.
@hypolite @jaywink Logfiles are great! But we also do have some config setting to store every received message into some files. This means that we can repeat the processing process until it is perfect.

@Heluecht @hypolite yeah I should add a "retry" button as well. Currently I need to resend the message from the remote once code has changed. But I usually write unit tests against the real payload so it normally works well.

Sign in to participate in the conversation
Diaspodon est une instance majoritairement francophone et généraliste. Aucun contenu du fédiverse n'est filtré par une décision d'administrateur ou de modérateur.