1. Forum
  2. General Discussion
  3. Scripts not properly installing
macheteYeti Author

Hello,

For about a week we've been struggling with script updates. When the user clicks the install button, the script is truncated and only some of the meta lines are visible. I believe this must be some kind of OpenUserJS outage, so I am hoping someone has some insights on how to ensure this does not happen

Marti Admin

Re: @macheteYeti:

For about a week we've been struggling with script updates.

What scripts to test against?

When the user clicks the install button, the script is truncated and only some of the meta lines are visible.

Working completely for me on your most recently updated script. Again what scripts?

I believe this must be some kind of OpenUserJS outage

Nothing in the error logs and is working for the tests that I just ran.

so I am hoping someone has some insights on how to ensure this does not happen

Tell your users to try a clean profile. Chrome itself bombed on several Windows machines recently and had to be reinstalled from scratch. Fx is having some issues elsewhere as well with some other sites.

In short nothing detected here. If you can give a solid steps to reproduce we'll look into it... otherwise the dreaded "Works for Me" stands for the moment with the vagueness you've given here. Ideally this should have been on development as an issue not production here... but I was doing my daily routines and saw this.

OUJS Admin

macheteYeti Author

Hi Marti,

Thanks for the response. The scripts we have encountered this on include the one you linked as well as:
https://openuserjs.org/scripts/macheteYeti/[LWAF]_Open_Saved_Searches_Hide
https://openuserjs.org/scripts/macheteYeti/[CCP]_Billing_Inventory_Services_for_Printavo_Online_Labels_v2

Impacted in Chrome (and Brave), Firefox. Yesterday I had one user reinstall Violentmonkey to no avail. I'm not sure any of my users would eagerly reinstall a browser to debug this, but if it recurs for me I will try. But to me it seems unlikely to be relevant.

I will do my best to document it next time, but as I said, it's intermittent. The same scripts which I have experienced issues with are working fine for now, so I am not sure that if I documented it the next time it occurred that you would be available to investigate.

The first time I noticed it, I managed to work around by updating the script with a new version, resulting in a successful install. This did not work during a later instance, however. So I'm not sure if something funky is going on with caching, but this doesn't seem a reliable solution.

I believe it has also impacted an auto-update as well. Going to confirm that on a Zoom with the affected user this afternoon.

Marti Admin

Re: @macheteYeti:

so I am not sure that if I documented it the next time it occurred that you would be available to investigate.

Yes then it can narrow down the UTC time in the logging and/or any other patterns that may emerge. Don't try to guess what is useful and what isn't here just yet.

I also just checked Violenmonkey code and it appears to be correct as well for the text/x-userscript-meta albeit your symptoms described are the opposite which is a use case that can't happen in normal circumstances. When that "partial" meta comes through capture it for your script and paste it in a code fence. If you want to potentially rule out a browser/extension caching issue with text/x-userscript-meta then please use the .meta.js routine described here. I've also seen alternate DNS providers (Cloudflare, etc) and/or proxies strip or even add headers, ignore headers, etc.... so perhaps this could be a choice for you.

I'm not sure any of my users would eagerly reinstall a browser to debug this

If it's profile corruption then create another profile and test it there with only the basics. i.e. no other extensions except the .user.js engine of choice with default settings. If it's browser corruption then there is no other choice.

OUJS Admin

macheteYeti Author

Hey Marti, Violentmonkey reports that the script you linked auto-updated on 10/16 @ 3:51:38 (UTC-5) in Chrome, resulting in the truncated script.

Here is a screenshot of the result:
enter image description here

Are you able to offer any insights based on this info?

Marti Admin

Re: @macheteYeti:

https://imgur.com/a/gID94hT

That's the meta routine alright.

Are you able to offer any insights based on this info?

Also reexamined a bit deeper with the Violentmonkey (VM) code at violentmonkey/violentmonkey/blob/6098f9e/src/background/utils/update.js#L101-L104 and that appears to be the culprit. It seems to be not doing a second call to get the full source data and just does a return of what it first retrieved from us (just the meta) with the text/x-userscript-meta header... which is highly probable why it's getting "truncated" by your .user.js engine.

Try this instead and report back:

--- /scripts/macheteYeti/[LWAF]_Open_Saved_Searches_Hide/source@7+9ee99d6
+++ /scripts/macheteYeti/[LWAF]_Open_Saved_Searches_Hide/source
@@ -8,7 +8,7 @@
 // @require     https://cdnjs.cloudflare.com/ajax/libs/arrive/2.4.1/arrive.min.js
 // @require https://raw.githubusercontent.com/phstc/jquery-dateFormat/master/dist/jquery-dateformat.min.js
 // @downloadURL https://openuserjs.org/install/macheteYeti/[LWAF]_Open_Saved_Searches_Hide.user.js
-// @updateURL https://openuserjs.org/install/macheteYeti/[LWAF]_Open_Saved_Searches_Hide.user.js
+// @updateURL https://openuserjs.org/meta/macheteYeti/[LWAF]_Open_Saved_Searches_Hide.meta.js
 // @author       macheteYeti
 // @description  Opens AC saved searches & hide recently active
 // @grant       GM_addStyle

... to see what VM is going to do with it next update cycle.

not seeing an edit button.

That's what the Preview button is for. Also more than likely imgur doesn't allow hot linking so the URL is the the best option.

To reiterate the importance of opening an issue like this on GitHub development (the link at the bottom of every page here on OUJS) I would have been able to summon gera2ld or tophf to the issue so they could look into it further. Since you chose here... you get to do this all over again on VM's repo with an issue there if you want your @updateURL and @downloadURL styling to not change.

OUJS Admin

macheteYeti Author

Re: @Marti:

Appreciate all your help in debugging this. I've implemented the change you suggested and will let you know how it goes. But I am a smidge unclear on what you mean by this:

if you want your @updateURL and @downloadURL styling to not change.

You proposed a change only to updateURL but this indicates I might need to do something else with downloadURL as well?

Maybe I'm misreading, but you seem relatively frustrated with my choice of forum. Almost as if there's some big banner that I shouldn't have missed that would have directed me to the place you consider the right place (there isn't - I checked). But I did also post on VM's GitHub.

Marti Admin

Re: @macheteYeti:

You proposed a change only to @updateURL but this indicates I might need to do something else with @downloadURL as well?

Nope. However VM handles updating when @downloadURL is absent it doesn't seem to do an update in the logic either. It should default to the install source for both of those keys... but then there is your issue of it not doing the 2nd call to get full source... and the final return.

Appreciate all your help in debugging this.

Welcome and thank you for all you've done.

but you seem relatively frustrated with my choice of forum.

Nope... listing that as a consequence (hands tied here) of not being able to fully assist you with the time allotted...

But I did also post on VM's GitHub.

... however that helps. Subscribed.