I used code from a github repo to make a lemmy repost bot from a reddit sub.
I tested it out, it seemed OK. So I let it run over night.
When I got back I found out it had been posting the same thing over and over again every few minutes. The account was banned for spam. But in the meantime it was very annoying to people. Also, there are a bunch of posts that can’t be removed because it’s impossible to remove federated stuff.
Is there a responsible way to test this stuff?
I don’t want to make spam, be annoying, etc. I feel bad about the spam bot.
Can you make your own community? If no one is subscribed to it, it shouldn’t federate anywhere, right?
Yes. Host your own Lemmy instance. It’s not that hard and can be run locally with no federation.
good call asking for a proper venue to test this, but how do you mean you can’t remove federated stuff? i was under the impression (from lemmy’s homepage) that one of the features is 100% complete deletion by replacing post/comment content with ‘removed by user’. is this not the case?
stub out collaborating servers and test it in isolation. Run it on a vm with limited network access.
As an old programmer, always build in checks for your systems. Keep a cache of posted articles and check it before posting so you know you haven’t posted this one yet.
When you let something run overnight, that’s going to go south somehow. If running overnight for the first time, throttle it to one post per hour. And not the same post. I’m the morning you check if it successfully posted a new article once per hour. Next let it post a little more frequently. Ease into your desired frequency once you have figured out all your edge cases and scale issues.
And so forth.
Also, don’t let it run against the live system the first time. Implement a “dry run” option which doesn’t post to Lemmy, but writes to a file or something similar. This way you can make sure nothing goes wrong in the parts aside from the Lemmy integration.
This is great advice, and to the OP, don’t feel bad. You’re really not an IT person of any caliber until you have experienced when I like to call the “Production Incident Experience”, or PIE. IT work is a job with unforseen consequences and hurdles, and we’ve all run into them at one point or another.
This being a learning experience, do what we’ve all done and learn from it. Now you can set up logging, whatif, sandbox instance, whatever you have to do.
You’re on the road to becoming a good programmer - just learn from your mistakes, do your research on best practices, ask intelligent questions, and in no time at all you’ll be writing one of these posts yourself.
