Hub resource has old version and new version of .var at the same time

ICannotDie

Well-known member
Featured Contributor
Messages
70
Reactions
1,400
Points
83
Website
www.patreon.com
I recently released this: https://hub.virtamate.com/resources/gwyn.43723/

When I was creating it I uploaded V1 of the .var in the editor and before publishing I realised it was missing something so I deleted the V1 upload and added the V2. After publishing it seems that both V1 and V2 are being offered when clicking download. Not a huge issue but a bit confusing for users... Also, there seems to be no way to remove or change the .vars by editing the resource. I'm guessing we can only change .vars by uploading a new version, which seems overkill to fix this minor issue...
 
The var naming convention is author.title.number.var. It looks like you followed this, but there are two versions in the post. You must have posted it that way. Sometimes people do that when there's a "clean" scene with very few dependencies, and a more elaborate scene with more.
 
The .var names were generated by VAM during package build. I 100% did not publish with both files, I'm sure of it. I distinctly remember deleting V1 before uploading V2. I even double checked it to make sure there was only a single.var listed before I published to ensure I had uploaded V2.
 
I will look into whether there is a bug, although off the top of my head it shouldn't be technically possible.

As for the ability to delete versions, I hope to find a way to do that in a later Hub update, but just so you know, it is technically complex due to the way the Hub is built and how it handles var packages. If it can be done, I'm hoping to have it rolled out within the next month or two. As for now, the only way to fix the mishap is to upload a new version of the resource and delete the previous version in your history tab. If you plan to do this, you should try to do it soon so that there aren't as many people out there using the old version.

In order to upload a v3 without having to change much, unzip the var using a tool like 7zip, add some screenshots, then re-zip using "zip" format and name it `ICannotDie.Gwyn.3.var` so that it does not trigger the Hub's automatic duplicate file validation.
 
I will look into whether there is a bug, although off the top of my head it shouldn't be technically possible.

As for the ability to delete versions, I hope to find a way to do that in a later Hub update, but just so you know, it is technically complex due to the way the Hub is built and how it handles var packages. If it can be done, I'm hoping to have it rolled out within the next month or two. As for now, the only way to fix the mishap is to upload a new version of the resource and delete the previous version in your history tab. If you plan to do this, you should try to do it soon so that there aren't as many people out there using the old version.

In order to upload a v3 without having to change much, unzip the var using a tool like 7zip, add some screenshots, then re-zip using "zip" format and name it `ICannotDie.Gwyn.3.var` so that it does not trigger the Hub's automatic duplicate file validation.
Thanks, I will look at doing that soon.

My guess is that the original deletion looked like it worked, but didn't, and the .var was still in the form but wasn't showing so when I published both .vars were sent to the server. I'm a web developer and that would be my first assumption (a client side UI bug, rather than issue server side).

It's not a major issue, I just thought it was unusual that I couldn't remove a .var when editing the resource, but I can understand why that might be tricky given the dependencies.vars have on each other.
 
Ok, I tried doing what you asked - uploading a new version with screenshot in root of .var and incremented version number - but it now shows 2 copies of version 3! I did notice that when I clicked Attach Files it opened the file browser, but when I selected the .var it didn't start uploading but just immediately opened the file browser again. The second time I selected the .var, it started the upload. It 100% only showed a single .var once the upload finished and seemed to publish ok, but now shows 2 copies of the new version.

There is definitely something odd going on with file uploads. Why it would open the file browser twice, allowing me to select the file twice, but only show one upload... I have no idea but I suspect a client side issue with initiating the upload.
 
Also, you mentioned automatic duplicate file validation but I was somehow able to upload two identical files with identical names. I guess the dupe validation doesn't get run on files that are uploaded together, it only checks previous files. Not a huge issue I suppose as it's kind of an edge case but seems like a bit of an oversight.

And one final thing... I recently did two other releases and neither of them had these issues. It makes me wonder if it was something to do with deleting the V1 upload on Gwyn that screwed the resource up somehow. It's the only difference I can think of between the releases

Tagging @AshAuryn so you definitely see this...
 
Last edited:
Also, you mentioned automatic duplicate file validation but I was somehow able to upload two identical files with identical names. I guess the dupe validation doesn't get run on files that are uploaded together, it only checks previous files. Not a huge issue I suppose as it's kind of an edge case but seems like a bit of an oversight.

And one final thing... I recently did two other releases and neither of them had these issues. It makes me wonder if it was something to do with deleting the V1 upload on Gwyn that screwed the resource up somehow. It's the only difference I can think of between the releases

Tagging @AshAuryn so you definitely see this...
Thank you for the additional information. I am looking into this now. I was a bit delayed fixing some other critical issues.

This is not the first report I've heard about two file browser windows opening. I haven't been able to replicate it myself. I do wonder if it's some kind of caching issue, but I have no way to test that.
Ironically, I just finished writing the code for a duplicate file check because of an unrelated issue. However, I don't think that will solve this problem. If the form is only showing one upload, then the duplicate check will pass. Hmm.

Since you are a web developer, on the tiny chance you see this bug again, after you attach the file with the "double file browser windows" bug, could you inspect the page and grab a copy of the raw html off the page? Thanks!
 
Thank you for the additional information. I am looking into this now. I was a bit delayed fixing some other critical issues.

This is not the first report I've heard about two file browser windows opening. I haven't been able to replicate it myself. I do wonder if it's some kind of caching issue, but I have no way to test that.
Ironically, I just finished writing the code for a duplicate file check because of an unrelated issue. However, I don't think that will solve this problem. If the form is only showing one upload, then the duplicate check will pass. Hmm.

Since you are a web developer, on the tiny chance you see this bug again, after you attach the file with the "double file browser windows" bug, could you inspect the page and grab a copy of the raw html off the page? Thanks!

I've attached a .zip containing (change the .txt extension to .zip):

1) A video of me using the post-update, which shows the file browser opening 3 times, but somehow resulting in only 2 uploads.
2) The raw HTML as it was after the process shown in the video.

I can replicate this issue every time I try to update this resource. I also get the same issue when attempting to post an update on any of my other resources.

I don't get this issue (multiple file browsers opening) when uploading on a new resource.

I have a feeling that is two separate issues:

1) My original Gywn upload where I uploaded V1 then deleted it and uploaded V2 before publishing somehow caused both versions to be sent to the server on the publish. As I originally said, I'm 100% certain that after deleting V1 in the editor, it was not showing on the page. I think it's data must have still been in the form somehow, and so it was submitted along with V2.

2) The post-update issue of opening multiple file browsers acts in a similar way, in that it uploads multiple files unintentionally BUT the editor shows both files so it is obvious that one needs to be removed.

If you need anything else please let me know, happy to send more information/video if you need me to try something specific or demo something in dev tools.
 

Attachments

  • post-update bug.txt
    4.1 MB · Views: 0
I've attached a .zip containing (change the .txt extension to .zip):

1) A video of me using the post-update, which shows the file browser opening 3 times, but somehow resulting in only 2 uploads.
2) The raw HTML as it was after the process shown in the video.

I can replicate this issue every time I try to update this resource. I also get the same issue when attempting to post an update on any of my other resources.

I don't get this issue (multiple file browsers opening) when uploading on a new resource.

I have a feeling that is two separate issues:

1) My original Gywn upload where I uploaded V1 then deleted it and uploaded V2 before publishing somehow caused both versions to be sent to the server on the publish. As I originally said, I'm 100% certain that after deleting V1 in the editor, it was not showing on the page. I think it's data must have still been in the form somehow, and so it was submitted along with V2.

2) The post-update issue of opening multiple file browsers acts in a similar way, in that it uploads multiple files unintentionally BUT the editor shows both files so it is obvious that one needs to be removed.

If you need anything else please let me know, happy to send more information/video if you need me to try something specific or demo something in dev tools.
Could you add me as a team member to gwyn? I'm going to try the form in the same browser.
 
Replicated bug on chrome in development. You can remove me as a team member, since it's not Gwyn specifically, and likely not due to your earlier issue with the two versions.
 
Replicated bug on chrome in development. You can remove me as a team member, since it's not Gwyn specifically, and likely not due to your earlier issue with the two versions.
I've removed you from the Gwyn resource. Good to hear you can replicate the issue, hopefully that'll make it easier to figure out what's happening.

I don't usually edit resources on my phone, but the hub is pretty good on mobile. Not perfect, but responsive and definitely usable.

Let me know if you need anything else.
 
Back
Top Bottom