Connect and Web UI submit access requests with different durations about teleport

[gzdunek]

Making a dry run call when the number of the added resources changes only fixes half of the problem.
The another part comes from the way AccessDurationRequest component is written. Because it keeps the list of options in its own state, it ignores any changes to the accessRequest.maxDuration prop.
There is a useEffect that updates this state when assumeStartTime changes, but ignores accessRequest.

When this was added, we talked that this is a React anti-pattern, and you planned to refactor that later.

I think that ideally it should work as below:

1. Get rid of all state and effects in AccessDurationRequest.
2. Duration options should be calculated at useRequestCheckout level (and useAccessRequestCheckout in Connect, respectively). These options shouldn't be kept in the state, but rather calculated dynamically.
3. The selected option should be kept at the top level in the component hierarchy, as it is now . We would update its value in the callback that makes the dry run call.
   • The ideal UX would be to update this value only if it is empty or not in the new list of options. But for simplicity we can always overwrite it after making the dry run call.
4. To avoid code duplication, I would keep that logic in a hook like useRequestDuration and use in Web UI and Connect.

@kimlisa do you have time do address this problem?

Alternatively, if we don't have time for such refactor, we could only add making the dry run call and adjust the useEffect to run when accessRequest.maxDuration changes.

[kimlisa]

oh that's so weird... i run into similar problem in the web UI where

• requesting from the access request page gives me the correct max (12 hours, fyi this is your session TTL, and it will be lower the longer you've been logged in)
• requesting from the resource list gives me max 8 hours

[gzdunek]

I think I know what's going on.
We used to make the access request dry run call when the checkout sidebar opened. However, in the unified resources it is opened permanently, so we make the call only when the component mounts (so we send an empty request and it returns that 4 minutes duration).

To fix this, we should make the dry run call every time the user adds a resource.
It also looks like we had a bug even previously, because we didn't make the call if the resource was removed from a request. I don't think this is correct, and we should always call dry run when the number of added resources changes, correct? cc @kimlisa

[kimlisa]

i'm in a good place to start refactoring and i'll tackle this today