Open bradchoate opened 2 months ago
I started with the method you describe here, it just means the bot requires manual intervention any time posting to Mastodon encounters an error. Related issue: https://github.com/MLTSHP/best-of-mltshp-bot/issues/4
I've wondered if ultimately the bot should live in the same part of the main code base that the Twitter bot lived in.
Regarding #4 - what would cause that kind of persistent post failure?
The technical answer is anything that reaches this line: https://github.com/MLTSHP/best-of-mltshp-bot/blob/main/best_of_mltshp.py#L92
I could reinstate the stateless version and see how long it takes to error out. There were more errors in the beginning that are handled now, so maybe it would be fine.
I think if there is some sort of problematic post, the script could keep trying until at least one posted successfully or no other posts were available. That would allow a problematic post to be bypassed, but still retried upon the next run.
I think what I want to do here is switch to a skip.log
file that is manually updated by a human, and have the bot alert a slack channel when it gets stuck on a file. I think simplifying what goes on in the workflow and removing the commit access is a good direction.
I don't see the utility of the
links.log
file and I'm wary of Github actions that have commit rights. The RSS feed from the Mastodon account should be the source of truth for post history. Thelinks.log
file only retains the last 200 post IDs, so it has similar limitations to the Mastodon RSS feed. Extract the post IDs posted to Mastodon from the feed with each run, and only post entries from the MLTSHP user account if they aren't in the feed.