19
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 24 Feb 2024
19 points (100.0% liked)
/kbin meta
2 readers
1 users here now
Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign
founded 1 year ago
I'll try to reproduce this and look into tightening the error handling. A 404 error should imply that the magazine is not available at the remote. Are those magazines available at the target instance? Agree that those should at least be added to the log--perhaps should add a third category for "Unavailable." Remember that it will also navigate you to the magazines list at the end for visual confirmation.
When you said community subscription, were you referring to something in particular, or just using this term generically to refer to magazines?
I haven't tried all of them, but the ones I did check were ones that had not had posts on them at their source instance for quite a while. A few random examples:
I had 43 failures and 111 successes, so visual inspection wouldn't really help. I kept copies of the error log and the script output in a text file to figure it out later.
I assume that this means these communities haven't had activity since fedia.io opened, and so fedia.io doesn't know they exist? I've always wondered how the first person to subscribe to a community on an instance is able to do that.
And yeah, I'm using "community" to refer to "magazine".
Hmm, this is a good finding. Just on a cursory review, I had a look at the magazines list on fedia, and it does list magazines with zero threads, comments, posts, or subscribers on them (on other instances other than kbin.social). So maybe you've discovered a problem with kbin.social's federation? I don't know too much about this issue, so this is just my initial reaction before looking into it further.
Addressing your issue, I have bumped the version number to 0.1.3 and made a change to the async method handling so that instances not available at the remote get added to the fail log correctly.
This doesn't explicitly address the fact that some instances are unfederated, but it will make the log results clean.
As for the federation issue, what I've initially found is that a user on an instance has to visit the remote instance for the home instance to be aware of this remote instance, and a user (could be a different user) has to subscribe to that instance for the posts to start federating. What is unclear is how a user on an instance visits a remote instance from the home instance, as this is implementation-specific and could vary from instanc to instance.