Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clicking on gateway list entry doesn't always redirect #1122

Open
Elson9 opened this issue Aug 8, 2024 · 11 comments · Fixed by #1146, #1162 or #1178 · May be fixed by #1217
Open

Clicking on gateway list entry doesn't always redirect #1122

Elson9 opened this issue Aug 8, 2024 · 11 comments · Fixed by #1146, #1162 or #1178 · May be fixed by #1217
Labels

Comments

@Elson9
Copy link
Contributor

Elson9 commented Aug 8, 2024

API Services Portal Issue

User Story

As an API Provider, I want to reliably select a Gateway and have it redirect to the detail page every time.

Test Case

ENV

  • [ x] DEV
  • [x ] TEST
  • [ x] PROD

TESTCASE

  • Go to detail page
  • Select a Gateway

EXPECTED

  • Rediects to detail page

ACTUAL

  • Sometimes doesn't redirect

ERROR

Notes

@Elson9 Elson9 added the jira label Aug 8, 2024
@timng-bcgov
Copy link

timng-bcgov commented Aug 12, 2024

I noticed that I only experience this issue the first time I select a Gateway from the list after I log in as a provider. Also, the toast pops up and I can see the URL/title metadata update briefly as well. Any subsequent navigation after refreshing the page or browsing elsewhere in the portal is OK.

@rustyjux
Copy link
Contributor

rustyjux commented Aug 13, 2024

This issue can occur in local env (docker compose) as well as dev. It is difficult to reproduce consistently.

I also observe what @timng-bcgov noted re: page title updating and then going back as it was. I didn't see the URL change but maybe my eyes are too slow.

My guess is either: A) some server side content is not readily available so the redirect fails, or B) there is a race condition where the router.push doesn't occur.

To address B) I tried adding an await on that in 6e1c3f5 and it seems to be working in detached local dev mode. I will validate with more testing in docker compose and in dev.

@rustyjux
Copy link
Contributor

Following the await change, I could not reproduce the bug in a handful of tests on dev and local docker.

I think we are good so I am going to close. If the bug continues to occur, I will set up a quick automated test to better validate any future fixes.

@rustyjux rustyjux reopened this Aug 19, 2024
@rustyjux
Copy link
Contributor

Still occurs in the current release in test (b902ab0)

@rustyjux
Copy link
Contributor

Still not resolved. The problem (which was attempted to resolve in #1146) ties back to NoGatewayRedirect pushing users back to list.

@Elson9 has suggested a 1 second setTimeout() or sleep() as a last resort.

I think if paired with some sorta visual loading something it might not be so bad. In general people shouldn't end up on a Gateways page without an active gw (except after logging back in).

What is not uncommon is people going from list --> detail so we really need to fix that.

A more polished solution for users logging in to a Gateways page (and being redirected away now) would be to add a query param to reactivate the last Gateway they were using.

@rustyjux
Copy link
Contributor

rustyjux commented Sep 12, 2024

It's back! Still need more work on this issue. If you rapidly go Gateways > Gateway detail > Gateway Services (or other subpage), the redirect back to Gateways occurs:
Recording 2024-09-12 at 15 57 00

@rustyjux
Copy link
Contributor

This still isn't resolved (all environments).

@rustyjux rustyjux reopened this Nov 28, 2024
@rustyjux
Copy link
Contributor

@Elson9 wrote in Jira (reminder to use GH)

Haven’t been able to reproduce the issue locally or in dev, test, or prod with Edge, Chrome, or Firefox. Maybe recent browser updates fixed it? Will have to park until next week to see if someone else on the team can reproduce.

I was just now able to reproduce (several times) in prod with Edge:
Image

The difficulty of reproducing definitely makes this bug tricky to tackle. I added tests to confirm the redirect happens when it should and does not happen when it shouldn't but apparently they aren't sensitive enough.

@Elson9
Copy link
Contributor Author

Elson9 commented Jan 2, 2025

Using window.location.assign('/manager/gateways/detail'); instead of await router.push('/manager/gateways/detail'); addresses the root issue of the failing redirect. There are some caveats however:

  • Performs a full page reload, so it's less efficient than router.push, which only updates the URL without a full reload.
  • The "Switched to Gateway:" toast no longer works, but a workaround can probably be made.
  • Isn't a best practice for an SPA.

Will set up further discussion with the dev team.

@rustyjux
Copy link
Contributor

rustyjux commented Jan 2, 2025

My vote here would be a 'no' on using window to do a full reload (option A let's say) - almost every time someone uses Portal they are going to go to Gateways and select a Gateway. So reloading the whole page for that seems icky (slower, aesthetically unpleasant).

Instead here are some options if we really can't get this working nicely:

option B: go back to old behaviour of showing 'First select a Gateway' in the page content

Recall we previously used to show an error on Gateway-requiring pages when there wasn't an active Gateway instead of the page content - I see that (and turning off redirect back to /gateways/list) as a better 'worst case' option. I don't believe this is a super common occurrence anyway - basically it happens if a session expires and folks log back in (which redirects back to their previous page). Or if they bookmark a page like https://api.gov.bc.ca/manager/products and then login there. So...

option C: return to gateways/list after login

Regardless of how we handle this issue (redirect working as desired or not), we could change the re-login to always bring you back to Home / Gateways List / Directory instead of saving the last page, if it's a Gateway-requiring page. This way, users are forced to re-activate a gateway instead of getting bounced there (by the redirect) or needing to nav there (if no redirect).

D: store most recent gw in local storage

(works with other options, but not logical combined with C)
If we wanted to reduce the chance of folks hitting a Gateway-requiring page w/o active Gateway (like after an expired session), I think we could store most recently used gateway in local storage. I believe we discussed this earlier and voted it down, but I think it's alright.

E: dynamic routing for Gateways

(also works with other options, but not logical with C)
Another better fix which would eliminate the problem would be adding dynamic routing, ie /manager/gateways/{gatewayId}/details, manager/{gatewayId}/products, etc though obviously a larger solution with added requirements.

Right now, I'd vote for B+D, but C is also a fine option worth considering.

@ikethecoder ikethecoder linked a pull request Jan 7, 2025 that will close this issue
@Elson9
Copy link
Contributor Author

Elson9 commented Jan 7, 2025

PR: #1217

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment