Bad fetchUrl takes down entire Portal UI in a multi-environment context

[jameshbarton]

Describe the bug A user accidentally provided an incorrect fetchUrl in an APIDoc for an already established multi-environment portal. In that scenario, the expectation is that the "bad" environment would not function. But any other environments should continue to operate. Instead, the entire portal UI returns a 404.

To Reproduce

1. Unpack attached resources in bad-apidoc-bug.tar.gz.
2. For this configuration, use /etc/hosts to point the following network addresses at $(glooctl proxy address): portal.solo.io, httpbin.solo.io, petstore.solo.io
3. Install petstore app to cluster.

   kubectl apply -f petstore-svc.yaml

4. Install petstore environment artifacts to cluster. Confirm that endpoint works.

   
   % kubectl apply -f dpe-petstore.yaml
   % curl http://petstore.solo.io/v1/api/pets -i
   HTTP/1.1 200 OK
   content-type: application/xml
   date: Tue, 21 Dec 2021 23:42:40 GMT
   content-length: 86
   x-envoy-upstream-service-time: 2
   server: envoy

[{"id":1,"name":"Dog","status":"available"},{"id":2,"name":"Cat","status":"pending"}]

5. Install httpbin environment artifacts to cluster. Confirm that endpoint works.

% kubectl apply -f dpe-httpbin.yaml % curl http://httpbin.solo.io/v1/get -i HTTP/1.1 200 OK date: Tue, 21 Dec 2021 23:43:28 GMT content-type: application/json content-length: 351 server: envoy access-control-allow-origin: * access-control-allow-credentials: true x-envoy-upstream-service-time: 57

{ "args": {}, "headers": { "Accept": "/", "Host": "httpbin.solo.io", "User-Agent": "curl/7.64.1", "X-Amzn-Trace-Id": "Root=1-61c266a0-37bdb4885a3f31436ec4626c", "X-Envoy-Expected-Rq-Timeout-Ms": "15000", "X-Envoy-Original-Path": "/v1/get" }, "origin": "35.237.29.174", "url": "http://httpbin.solo.io/get" }

6. Install user dev1 with password Pa$$w0rd.

kubectl apply -f group-user-passwd.yaml

7. Install Portal artifact that displays both environments. Confirm that you can login to portal at http://portal.solo.io (username dev1, password Pa$$w0rd) and exercise both sets of APIs. This should work as expected.

kubectl apply -f portal-both.yaml

7. Change httpbin APIDoc to point to a bad `fetchUrl`.

kubectl apply -f bad-apidoc-httpbin.yaml

8. Revisit http://portal.solo.io. Observe that the entire portal interface returns a 404.

**Expected behavior**
"Good" environments should continue to be served by the Portal interface. The entire Portal UI should not respond with 404.

**Additional context**
Add any other context about the problem here, e.g.
- Gloo Portal version 1.1.2
- Gateway technology and version (Gloo Edge Enterprise v1.9.1)

[jameshbarton]

Does fix for #153 also resolve this issue?

[soloio-bot]

Zendesk ticket #652 has been linked to this issue.

[bewebi]

We have release a UX improvement that eliminates the case was users were shunted to the 404 page any time a Portal was placed in Processing state This should eliminate the case where applying a bad resource temporarily brings down the Portal UI