Reporting issues? General question... closed bug that is still a bug

So Unity 2019.4.12f1 started crashing on me on my project when hitting play, so then I backed up the project, deleted the library folder and upgraded to 2019.4.19f1, to have it have the exact same issue, ok, fine, so then I deleted the library folder again and upgraded the project to 2019.4.28f1 to experience the same issue, I deleted the library folder 10 times before the issue went away. Now, I had submitted a bug issue on it to get a response that they already know of the issue and that it is fixed in 2019.4.22f1, end of discussion.

Wait..

Fixed in 2019.4.22f1.. still a problem.. the thread is locked for further up voting to get someone to fix it.. because.. well.. its ... fixed... 6 versions prior, but is still an issue and only solution is to basically be told they know about the problem and its fixed. But I am using 2019.4.28f1 and it was still an issue.

That all said, what is the process when support responds that it is fixed, see this article that it is fixed, but obviously it is not fixed? What is the next steps? All I could do is request that the original issue that is marked resolved and locked for voting to be unlocked because, well, its not resolved yet.

Unity Issue Tracker - Crash with GenericRemote::CheckAndroidSDKPath when entering play mode (unity3d.com)

That is the article I was pointed to, but I am doing a Windows build, not Android, its not even set for Android, which I presume is probably why it is generic and throws a generic error for something that I am not even attempting to do on a platform I am not even using.

It doesn't matter how many new bug reports I would submit on the same issue on 2019.4.28f1 because it existed in 2019.4.12f1, 2019.4.19f1 and 2019.4.28f1 and the article on it is closed.

I guess I am simply frustrated, at the very least, after wiping my library folder 10 times it eventually worked, so that work around still works but the bug still exists and I have no outlet to report it from what I see.

 

Maybe read the emails you get from QA? They specifically tell you that if you have further comments on the bug you're reporting, answer the email. At least all my answer emails contain that and when I follow up on things QA reads it. So maybe you should follow instructions or something? There is your outlet.

You know, QA and engineers in general are human beings, they even make mistakes sometimes. Instead of boiling your frustration, you may want to talk to them. Just pull up the email where they told you that they are closing your bug because it's fixed in a version, answer to it and describe that you're using a later version and you still experience the issue.

 

As you can see, I "read" the response and I "read" the linked article, and I also had submitted the bug twice on different versions. And I also responded with asking to re-open the case so that I could up vote to get what is fixed, fixed. I am not even here asking for support, just wondering in general, when a bug is closed as resolved and is still a bug, and pointed to a solution that it is solved, but it is not solved, but honestly I expected someone to attack me over the frustration, that was an obvious, but not arguing with you about it, it just is frustrating to report it on a version past the fixed version and be pointed to a version that it was fixed on which is older than the latest I tested it on pretty much. The work around is the same workaround it has always been, delete the Library folder over and over, re-open the project and let it rebuild, until, well, it works. So, just frustrated at the engine, not QA. They found the article where it says it was fixed, but I can't up vote to have it fixed because it is locked.

 

You did not mention it, only mentioned one.

You did not mention it.

I mentioned it above. Answer to the email you got that they will close your bug report. Tell them that you have later version and you are on Windows target and experiencing the crash despite that they said it is fixed.

That's understandable. But you still need to talk to QA, it won't be solved here on the forums.

Yes, all closed bugs are disabled. There is no meaning to vote on a bug which is closed already, no one will see your vote. Again, talk to the QA, get them to reopen your case and then you can vote on it (although I never understood the voting system, it is utterly unnecessary and placebo).

Sorry if you feel my words as attack, it isn't my intention. But really, instead of a forum post, you should write answer emails to QA and describing things to them in details. And no, your initial post doesn't tell us that you did that.

 

Honestly I did respond to the QA about it, haven't heard back yet, but since it is resolved in an earlier version, and she responded that it was resolved with the link to the resolution, which is what, 6 version prior in updates, I do not suspect I will hear back without submitting another ticket, which is redundant. I can handle the work around, this is not a show stopper, just an annoyance when it breaks. So far on 28, I have had to kill the Library folder 8 more times and allow it to rebuild, so its just annoying. But on this issue, I do not see a solution. Probably a regression issue or the original "fix" wasn't actually a fix but they thought it was since it is inconsistent, and those bugs are the worst. It appears to be fixed, then 5 or 10 loads later of the project, hitting play, engine blows up, same problem, repetitive. I personally hate those kinds of issues.

 

I would re-report it, link to the ticket which shows it as "fixed" and specifically call out that it's occurring again in a later version. I would be tempted to call it a "regression".

It's possible that it's a legitimate regression, ie: they did fix it, and something has caused it to come back again.

 

If you're using git for source control, a better option is to close Unity and your code editor, and run the following command...

git clean -f -x -d

This removes anything not checked into your source repo, and once you open the project in Unity again will do a complete reload. I've always used this when I've ran into Unity weirdness and it's saved me many times.

 

Accept that it will not be fixed, at the very least not in time for it to matter.

Best case scenario if you get through to QA and they reproduce the issue, it will take them at least 6 months for the fix to be in a build you are using (if they still support 2019LTS at that point), and is that potential pay off worth the effort of trying to convince Unity that bugs are bugs?