Can't update userscript

[qsniyg]

What happened?

Normally my userscript (https://openuserjs.org/scripts/qsniyg/Image_Max_URL) auto-updates when the source (https://github.com/qsniyg/maxurl/blob/master/build/userscript_extr_min.user.js) updates, but it failed to update this time for some reason.

I tried manually updating it, but it sent the error "Payload is too large". It's ~652KB, which is under the 1MB limit.

What did you expect to happen?

It should have been auto-updated.

What the problem might be?

No response

[Martii]

• Your full sized script direct from GH is 6.1 MiB (6,388,586)
• Your smaller one is 3.1 MiB (3,252,675).
• Your compressed one is 652.0 KiB (667,621)

Your installation URL is https://openuserjs.org/install/qsniyg/Image_Max_URL.user.js which means your phantom usersript_extr_min.user.js won't be doing much unless it has a created homepage on OUJS.... which it does not at the time of this writing. I only see one script on your account and that is the only one that is possibly syncable at this time if the size is within the limits. i.e. this is inteneded behavior.

I tried manually updating it, but it sent the error "Payload is too large". It's ~652KB, which is under the 1MB limit.

This part is a known issue at #793 and is a duplicate. Best to utilize properly the webhook instead at this time.

[qsniyg]

Thanks for your response, I fixed it by creating a dummy commit only changing extr_min: qsniyg/maxurl@4212e1f

For some reason it said "OK" for the previous extr_min script, but then failed to sync regardless. Maybe this is because userscript.user.js was changed in the same commit, and it tried to sync that one afterwards?

[Martii]

For some reason it said "OK" for the previous extr_min script, but then failed to sync regardless

That was confirmed by me when you opened the issue... however... I did match a portion of your repo files and it synced both (because they are both within limits). All I can think of is that this time of year the bad actors like to get out more and attempt to drag the site down. There is also the possibility that GH rate limited us. They like to do that more now.

Maybe this is because userscript.user.js was changed in the same commit, and it tried to sync that one afterwards?

Because you are reusing the @name for all of them there is no guarantee on the order of processing and timely processing. This is described under the caveats section. As far as it not syncing there have been multiple reconnects with the MongoDB so perhaps you hit a spot where it wasn't connected. Unfortunately all failure paths still aren't fully trapped and that dependency could be to blame as well including the binary.

Because I can't reproduce it I'll have to leave the labels as is but I'll keep my eyes out for anything out of the unusual.