Feature request: Configuration option to terminate (exit) application when banned

[runecalico]

@Tyderion First I would like to thank you for providing this CLI version of aniadd, as well as working to improve it.

One annoying thing about the current implementation is that when you invariably get banned from the API, the client continues to check (which I believe just elongates your ban).

Would it be something you would be willing to add as an configuration option that when Banned from the API, the application terminates (Exit)?

I suggest a configuration option (default false) as that would be a good way to add the functionality without changing the application's default behavior.

[Tyderion]

hey, thanks for the feedback. I'm currently working on a rewrite of the udp api (and other parts) to adhere to the given rate limits of the anidb specifications (1 req/4 seconds over a long period of time, which seems to be your usecase). The next version (4.x) should never get you banned anymore 🤞 But i think having a flag / config option for to shutdown if you get banned makes sense anyway, i'll include that as well.

I think i'll be able to release it soonish (it's mostly done, but not thoroughly tested yet).

[runecalico]

I'm "in the middle" of running aniAdd against several TB of files, so I'll try the branch and let you know what happens :)

[Tyderion]

good luck :) I've pushed multiple updates today, i think it should be ready, though the command syntax has changed (i did update the readme though). Easiest is probably using docker, but you can always run it directly. Your config might be incompatible (property renameFiles was duplicated and doesn't exist anymore), rest should be migrated automatically (there's a command to read and then save your old config again)

[runecalico]

It seems that the exit on ban flag still needs some work, when a fatJar is compiled from the first commit where that feature was added .. when I got banned it still kept on going ..

2024-07-23 14:59:06 FINE udpapi2.ParseReply parseReply Reply: 555 BANNED \n 
2024-07-23 14:59:06 WARNING udpapi2.UdpApi addReply Reply without corresponding query Reply(fullMessage=555 BANNED
, fullTag=555, replyStatus=null, queryId=null, responseData=[])

It did take awhile, I got banned on file 39794 (out of 56k or so)

I'll try compiling from the branch again once it seems that you might be at a lull of adding more commits :)

[Tyderion]

yeah, i mostly get to work on this at weekends. I had hoped you would not get banned at all though, as it should not send queries fast enough for that to happen. I guess i'll have to look into that at a later point. Did it log SEVERE [...] User is banned. Exiting. at any point after you got banned? Because if not then the whole flag isn't working yet (I did not test it tbh, but i'll make sure to verify it's working before merging)

~~ Additionally it should have logged somethign like WARNING [...] Fatal api error, waiting a long time: [something]. I would assume this did not log, right?~~ OKay you gave me all the info i need to fix it. Fix will be pushed today and it's definitely not fixed in the version you're currently testing. If the reply has no corresponding query (which the BANNED message never has) it's corresponding handling is not done 🤦‍♂️

[runecalico]

It did not log SEVERE [...] User is banned. Exiting. nor WARNING [...] Fatal api error, waiting a long time: [something] I am using this for the logging properties

# Both .level and ConsoleHandler.level must be set for the level to take effect. Don't ask me why.
.level=FINEST
java.util.logging.ConsoleHandler.level=FINEST
java.util.logging.SimpleFormatter.format=%1$tF %1$tT %4$s %2$s %5$s%6$s%n

Do you believe the current commit on the PR branch is stable enough to use? I can recompile and use the latest branch if you feel that would be helpful

[Tyderion]

I just pushed another commit to improve (and fix some parts) of handling fatal replies. I think now it should be stable.

When --exit-on-ban is set it should terminate after receiving a BANNED, if it is not set it should wait an hour before continuing. In the second case I will have to check if it loses the command that failed (but that's a bit more difficult to test so i'll do it on the weekend)