Octo website wont load after upgrading to 2020.3.1

Octo website wont load after upgrading to 2020.3.1 from 2020.2.16.

The service runs fine but the site wont load.

Hi @ShrapnelStudios,

Thanks for reaching out.

Did anything else change during the upgrade? web bindings? service accounts? other infra changes or software upgrades?

Which browser are you attempting to use? Do other browsers have the same issue? What is the error that you’re getting trying to reach the portal?

If you put you manually add /app to the end of the url, does the portal load?

Are you local on the intranet or outside on a vpn?

Thanks,
Jeremy

sorry i dont have anything as far as error logs to give you because once i saw it was not working i immediately reverted back to 2020.2.16.

no infra/web bindings/service account changes

I tried with Edge and Chrome and both did not work. the error on both was “The site can’t be reached - took too long to respond - ERR_CONNECTION_TIMED_OUT”

I didnt get to try to add /app at the end of the url.

Hi @ShrapnelStudios,

Let me reach out to the engineers and see if there was a fix put in place for this. I’ll update you when I get more information. Please feel free to reach out in the meantime.

Thanks,
Jeremy

Hi @ShrapnelStudios,

I spoke with our engineers and the issue I was thinking of was due to a user’s proxy. Do you all have a proxy? If so the rules might need to be updated to resolve this going forward.

Please let me know what you think.

Thanks,
Jeremy

I don’t think that is the issue since when i roll back everything works fine.

I can try to update again - is there any certain logs you want me to grab?

Hi @ShrapnelStudios,

The problem is that in the new version an extra slash is getting added, so on the proxy it needs to be changed from http://octopus/{UNENCODED_URL} to http://octopus{UNENCODED_URL}. With the slash in there, it causes an issue in the latest version. Do your proxy settings look similar?

Thanks,
Jeremy

we do not use a proxy

Hi @ShrapnelStudios,

I would hate for you to update and be stuck again, but that may be the only way we can troubleshoot this. You should be able to get to the portal by putting /app at the end. If you do upgrade again, we could use some server logs, screenshots of how your browser is acting, and the HAR file from your network tab would be helpful. If you’d like, if you let me know what time you’re going to upgrade I can try to be available for questions in case something goes wrong.

Is it possible to make a database backup and spin up a second instance somewhere as a test?

Please let me know what you think.

Thanks,
Jeremy

I’d like to add that I just experienced the same issue. I upgraded to 2020.3.2 and the site will no longer load. I tried on the localhost binding we use as well as through the reverse proxy. I reapplied the bindings and nothing has worked. This is the first upgrade since 1.0 that has not worked for me.

Hi Brian,

Thanks for reaching out.

Did you roll back or are you still on it?

If you add /app manually to the end of the url does it load in?

Thanks,
Jeremy

I have not rolled back. Is that an automatic process, or do you mean I should restore it from a backup?

I’m hosting the site on http://localhost:88/

I’ve tried: http://localhost:88/app/, http://localhost:88/app, http://localhost:88/, http://localhost:88 and none of those work. I also tried adding a :89 binding and that failed as well.

Hi Brian,

No it would be restoring from a backup, but we won’t be able to troubleshoot this very easily if you roll back right away. Would you be able to troubleshoot a bit before you rollback?

Did you also change the settings described above in the proxy?

http://octopus/{UNENCODED_URL} to http://octopus{UNENCODED_URL}

Thanks,
Jeremy

I can keep it broken for a while if that would help. I am using IIS URL Rewrite to do the proxying with the following action URL: http://localhost:88/{R:1}

Is this what you’re referring to? Since it is broken even on localhost, this shouldn’t apply, right?

Hey Brian,

Are you able to remove IIS from the setup easily just to test and see if it works? You should also not need the / at the end of the port in the url.

If that doesnt work would you be able to DM me the upgrade logs and the server logs?

Thanks,
Jeremy

I just sent you a DM with my server logs. Also, wouldn’t using localhost:88 bypass IIS and go straight to the hosted service?

Hey Brian,

I do believe the IIS will still intercept there.

Would you be able to do the following as a quick test:

Stop the IIS service
Bind localhost
test loading the portal.

Thanks,
Jeremy

Stopping IIS and hitting http://localhost:88/ immediately worked and caused a redirect to http://localhost:88/app#/users/sign-in

Hey Brian,

I’m glad to hear we found something. Is there another purpose for that IIS Proxy other than Octopus? Do we need to bring it back into the equation?

Thanks,
Jeremy

Yes, I’m using it to reverse proxy another site as well on our build server (TeamCity), but it can stay offline for a bit to test as well.