feat: [M3-8335] - Link Account Limit ticket in more flows with error notice - #10684
Conversation
|
Coverage Report: ✅ |
| const generalError = | ||
| typeof _apiErrors[0].reason !== 'string' | ||
| ? _apiErrors[0].reason | ||
| : _apiErrors | ||
| .reduce( | ||
| (result, { field, reason }) => | ||
| field ? result : [...result, reason], | ||
| [] | ||
| ) | ||
| .join(','); |
There was a problem hiding this comment.
The misleading string type of _apiErrors was resulting in [Object object] being displayed to the user in any case where the error was already globally intercepted converted to JSX, as support errors were.
I'm proposing that we remove the global intercept for support tickets in this PR, but we still global intercept for verification and migrate errors, so I left the change in this util.
| { | ||
| condition: (e) => { | ||
| return ( | ||
| (!!e.reason.match(/.*open a support ticket/i) || | ||
| !!e.reason.match(/contact Support/i)) && | ||
| !e.field | ||
| ); | ||
| }, | ||
| replacementText: <SupportError errors={errors} />, | ||
| }, |
There was a problem hiding this comment.
Ultimately, I think we should remove this and handle support errors at the component level. As we begin to add more ticket types, it will depend on the context of the component which type of ticket we link to, so it is no longer useful to override at a global level to open a general support ticket. Additionally, our lack of type safety for a reason that is either string or JSX adds complexity and errors (see the [Object object] in Volume Create; another place this happens is the Configuration dialog when hitting a VLAN limit). We could mitigate these if we leave the construction of JSX to ErrorMessage.tsx and SupportTicketGeneralError.tsx.
If we do this here, in this PR, some API errors not covered in this PR will no longer link directly to a support ticket. If we're okay with that for now, we can proceed and create a follow up ticket to use ErrorMessage with general errors throughout the app - or at least where we think "contact support" API errors are likely.
There was a problem hiding this comment.
I'm good with this! The interceptor solution was handy, but I'm much more sold on handling at the component level.
I remember @hkhalil-akamai saying we might even be able to remove the migration and verification interceptors as well because they might not be returned by the API nowadays, but I might be wrong. We can investigate that at a later point.
bnussman-akamai
left a comment
There was a problem hiding this comment.
Looks great! I like how we're handling errors at the component level now.
@hana-linode That would be ideal, agreed. It felt like it would be more complicated than it's worth when I was first implementing, but I'll revisit now that this is a much smaller PR. 👀 |
The way that we're converting special ticket type form fields into one description field makes this messier than I'd like. I'm going to hold off on it unless we get feedback from customers/Support that 'entities' is confusing. |

Description 📝
#10620 focused on the creation of the new account limit support ticket, linking to it from the Linode Create flow, and providing test coverage.
This ticket will link to the the account limit support ticket from the "contact Support" text on the Volumes, NodeBalancers, Firewall, Kubernetes (LKE create and Add a Node Pool), and Database create flows. Currently, the link in these flows takes users to a general support ticket.
Changes 🔄
handleGeneralErrorFormik util that didn't account for the APIError reason being a string or JSXTarget release date 🗓️
8/5/24
Preview 📷
Videos 🎥
Screen.Recording.2024-07-16.at.2.04.16.PM.mov
Screen.Recording.2024-07-16.at.2.07.46.PM.mov
Screen.Recording.2024-07-16.at.2.04.50.PM.mov
Screen.Recording.2024-07-17.at.11.50.54.AM.mov
Screen.Recording.2024-07-16.at.2.06.47.PM.mov
Screen.Recording.2024-07-16.at.2.06.47.PM.mov
Screen.Recording.2024-07-16.at.2.08.42.PM.mov
Screen.Recording.2024-07-16.at.2.07.12.PM.mov
How to test 🧪
Prerequisites
(How to setup test environment)
Verification steps
(How to verify changes)
In admin, set your thing limit to 0.
For each of the above create flows (Volumes, NBs, LKE Create + Add a Node Pool, Firewalls, Databases):
Fill out the create form and try to create the entity.
Confirm that the UI displays an error notice when user has reached a limit on their account:
You’ve reached a limit for the number of active services on your account. Please contact Support to request an increase and provide the total number of services you may need.Click on the "contact Support" link and confirm that you are redirected to the Account Limit ticket and the expected fields show.
For LKE only, setting your reputation to 0 should result in the error:
A limit on your account is preventing the deployment of the selected service. To request access, please contact Support and provide the service name.You should also link to an account limit support ticket.Verify that this test isn't flaking in CI:
As an Author I have considered 🤔
Check all that apply