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.

Sign up for GitHub

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

fix(Settings): Prevent warning to be displayed when no settings is returned by the Settings API #384

Merged
merged 3 commits into from
Feb 6, 2025
Merged

fix(Settings): Prevent warning to be displayed when no settings is returned by the Settings API #384

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6287059
fix(Settings): Prevent warning to be displayed when no settings have …
grafakus Feb 6, 2025
b96b821
Merge branch 'main' into fix/settings-not-found
grafakus Feb 6, 2025
5e02796
build(*): Trigger Build
grafakus Feb 6, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 2 additions & 6 deletions src/shared/infrastructure/settings/settingsApiClient.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,14 +13,10 @@ class SettingsApiClient extends ApiClient {
.fetch('/settings.v1.SettingsService/Get', { method: 'POST', body: JSON.stringify({}) })
.then((response) => response.json())
.then((json: ApiResponse) => {
if (!json.settings) {
return {};
}

const setting = json.settings.find(({ name }) => name === SettingsApiClient.PLUGIN_SETTING_NAME);
const setting = json.settings?.find(({ name }) => name === SettingsApiClient.PLUGIN_SETTING_NAME);

if (!setting) {
throw new Error('Setting not found!');
return {};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In what case it could happen? Could we log it to faro?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the same reasons as above, in the code that was removed: the API could return settings with an empty array or - as seen this morning, settings which contains only a list of exported metrics without any plugin settings. These are edge cases that could occur when visiting the plugin for the 1st time so we prevent the user to see a warning toast when landing.

In both case, IMO the UI should be flexible in this aspect. Now, if the API request fails or if storing new settings fail, the UI should display an error message and it should be logged to Faro. Wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the API could return settings with an empty array or - as seen this morning, settings which contains only a list of exported metrics without any plugin settings

If this is an actual API error why don't we let the customer know that settings are not loaded?

These are edge cases that could occur when visiting the plugin for the 1st time so we prevent the user to see a warning toast when landing

Or is it more of an expected / by-design behavior that when loading the plugin for the first time settings are not returned until they are saved? Could we populate empty settings in the backend upon first retrieval?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is an actual API error why don't we let the customer know that settings are not loaded?

It's not an error when the user lands for the first time on the app, they shouldn't see a warning toast. By design the Settings API is flexible. I understand your concern, we can strengthen the contract later IMO.

}

return JSON.parse(setting.value);
Expand Down
Loading