Skip to content

fix(web): fix TPM check when using the legacy AutoYaST mode#1927

Merged
imobachgs merged 3 commits intomasterfrom
fix-using-tpm
Jan 21, 2025
Merged

fix(web): fix TPM check when using the legacy AutoYaST mode#1927
imobachgs merged 3 commits intomasterfrom
fix-using-tpm

Conversation

@imobachgs
Copy link
Copy Markdown
Contributor

Problem

When using the legacy AutoYaST mode, the web UI crashes at the end of the installation when trying
to find our whether it is using TPM or not.

Solution

Properly handle that case:

  • fetchConfig now returns null instead of undefined. According to TanStack Query
    documentation
    , queryFn
    Must return a promise that will either resolve data or throw an error. The data cannot be
    undefined
    .
  • usingTpm function now handles the case where the configuration is null.

Testing

  • Tested manually

Copy link
Copy Markdown
Contributor

@joseivanlopez joseivanlopez left a comment

Choose a reason for hiding this comment

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

LGTM

@imobachgs imobachgs merged commit fa72f8e into master Jan 21, 2025
@imobachgs imobachgs deleted the fix-using-tpm branch January 21, 2025 09:57
@teclator
Copy link
Copy Markdown
Contributor

LGTM

// TODO: use type checking for config.
function usingTpm(config): boolean {
if (!config) {
return null;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Just a note.

Would be nice to be consistent in the way we return early from a component to tell React renders nothing.

I for sure know that no matters if you return undefined or null, React will understand both of them as nothing. But we used to go for

if (something) return;

Which returns undefined, the default return value for a JavaScript function.

Now we've a small dilemma with it comes to consistence because, as stated in the PR, react-query requires the query returns always something (null meaning nothing).

We can, of course, choose a default return value for everything or one for components and another for queries, but betting for consistency in each case for easing code maintenance.

@imobachgs imobachgs mentioned this pull request Feb 26, 2025
imobachgs added a commit that referenced this pull request Feb 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants