403 Error caused by rate limit

[JakeK34959]

I was getting a 403 error tied to an HttpError: "API rate limit exceeded for user ID 12345678", I figured since I couldn't find anything else in here about a 403 error besides the fact that it's common, that I'd throw my two cents in here. Force reload and rebooting obsidian didn't work, I found the quickest solution was just uninstalling and reinstalling the plugin but that was only simple because my settings are very basic as I am just using this to create an off site duplicate of my vault. I personally think it would be nice to know the rate limit especially for those pushing large amounts of changes, it'd also be nice to know if it will eventually work itself out after a certain amount of time like programs with rate limits. All in all a very simple error with a simple cause that's just lacking the proper documentation for those with less experience.

[Mara-Li]

To be honest, I never touch the limit rate!
How much file you send, by curiosity?

According to github doc, the limit rate:

User access token requests are limited to 5,000 requests per hour and per authenticated user. All requests from OAuth applications authorized by a user or a personal access token owned by the user, and requests authenticated with any of the user's authentication credentials, share the same quota of 5,000 requests per hour for that user.

[JakeK34959]

Useful yes but i feel like that would difficult to actually execute, an easier option would be to block multiple commands from running at the same time, just throw out a please wait for your last command to finish message, and for larger vaults that may have 5k+ notes to upload or refresh (i doubt it would happen but who knows) give a pop up to let the person know that they either need to set x amount of notes to not share at the same time/ in the same 1h period or have the command wait so when it hits note 4999 it waits 1h and then dumps the rest of the files or use github desktop app to manually push all the files at once and that way next time they run a refresh or upload it won't have as many files to push.

[JakeK34959]

And something I just realized, not only will the first publish of a large vault cause problems but for example I made a few file name changes and new files that lead to 349 changed files with 1,582 additions and 30 deletions, this becomes a problem with the vague language in the the GitHub documentation, I mean do the consider each addition and deletion a request or just each changed file so that would require either more research into api and rate limit or experimentation with a large obsidian vault, I could test it but I wanted to pop this in before I have to go out, I would also like to say that despite this back and forth of me giving recommendations for new features and what not, I do find this plugin to be amazing and a god send for those who want public vaults and those like myself that just want a offsite backup of a vault with version control in case of hardware failure.

[Mara-Li]

I want to warn you, my plugin is absolutely not made to make vault backup. You need to use the plugin GIT to do that. My plugin makes some transformation to your file that may break your vault, and… Well. I use the GitHub REST API, so there are some limits, as you see.

[Mara-Li]

Also, about set a limit for commands, it's not possible as I don't want to use node package (for keeping the compatibility with mobile).

[JakeK34959]

I want to warn you, my plugin is absolutely not made to make vault backup.... My plugin makes some transformation to your file that may break your vault,< Really cause I notice no change to the raw data so at least in my opinion from what I've noticed the only down fall right now is the rate limit. Plus worst case scenario I just need to make sure I run a manual push every couple of months just to make sure I have a solid copy in case of a hardware failure although not having a solid version would be the LEAST of my concerns if I'm dealing with a hardware failure.