Feat/onboarding internal boot

[Ajit-Mehrotra]

Summary by CodeRabbit

• New Features

  • Added Internal Boot configuration step to the onboarding process, allowing users to set up bootable pools with customizable slot allocation, device selection, and boot partition sizing.
  • Enhanced disk information display with additional device metadata.
  • Added boot eligibility detection and boot transfer configuration options to system settings.

• Documentation

  • Added documentation detailing onboarding interface behavior differences.

[coderabbitai]

Walkthrough

This PR introduces internal boot functionality across the stack. It adds boot-related fields to API state types (bootEligible, enableBootTransfer, reservedNames), disk metadata fields (emhttpDeviceId, sectors, sectorSize), a new onboarding step component for internal boot configuration, supporting store state management, GraphQL queries, and helper composables for submitting boot configurations.

Changes

Cohort / File(s)	Summary
API GraphQL Schema & Type Definitions api/generated-schema.graphql, api/src/core/types/states/var.ts	Added six new fields: Disk gains emhttpDeviceId, sectors, sectorSize; Var state gains bootEligible, enableBootTransfer, reservedNames. All additions are optional except bootEligible which is required.
API Disk Service & Emhttp Integration api/src/unraid-api/graph/resolvers/disks/disks.model.ts, api/src/unraid-api/graph/resolvers/disks/disks.service.ts, api/src/unraid-api/graph/resolvers/disks/disks.service.spec.ts	Introduced emhttp device data fetching and mapping to disks. Added internal helpers to normalize device names, parse numeric values, and enrich Disk objects with emhttpDeviceId, sectors, and sectorSize from emhttp device records.
API Var State Parsing api/src/store/state-parsers/var.ts, api/src/__test__/store/state-parsers/var.test.ts	Extended VarIni type and parse function to handle new boot-related fields, with bootEligible converted from string to boolean using iniBooleanToJsBoolean helper.
API Test Updates api/src/__test__/store/modules/emhttp.test.ts	Updated test expectations to include new bootEligible field in varState assertions.
Web Onboarding Internal Boot Step Component web/src/components/Onboarding/steps/OnboardingInternalBootStep.vue	New Vue component implementing the internal boot configuration UI (739 lines). Fetches boot context via GraphQL, manages form state for pool name, slot count, device selection, boot size presets, and BIOS updates. Validates user input and persists selection to draft store.
Web Onboarding Modal & Step Registry web/src/components/Onboarding/OnboardingModal.vue, web/src/components/Onboarding/OnboardingSteps.vue, web/src/components/Onboarding/stepRegistry.ts, web/components.d.ts	Added INTERNAL_BOOT step to onboarding flow with conditional visibility based on partner build status and boot transfer enablement. Registered step in step registry with metadata and component mapping.
Web Onboarding Store & State Management web/src/components/Onboarding/store/onboardingDraft.ts	Extended onboarding draft store with internal boot state: internalBootSelection, internalBootInitialized, internalBootSkipped, internalBootApplySucceeded. Added setters and persistence logic with normalization helper.
Web Internal Boot Composables web/src/components/Onboarding/composables/internalBoot.ts, web/__test__/components/Onboarding/internalBoot.test.ts	New composable exporting submitInternalBootCreation and submitInternalBootReboot functions. Handles POST requests to mkbootpool.php and Boot.php endpoints with CSRF token inclusion. Includes payload parsing and response handling with fallbacks. Comprehensive test coverage for both submission functions.
Web GraphQL Queries web/src/components/Onboarding/graphql/getInternalBootContext.query.ts, web/src/components/Onboarding/graphql/getInternalBootStepVisibility.query.ts	New GraphQL query files defining GET_INTERNAL_BOOT_CONTEXT_QUERY and GET_INTERNAL_BOOT_STEP_VISIBILITY_QUERY for fetching boot context data and visibility flags.
Web GraphQL Type Definitions & Operations web/src/composables/gql/graphql.ts, web/src/composables/gql/gql.ts	Extended Disk and Vars types with new optional fields. Added GetInternalBootContextQuery, GetInternalBootStepVisibilityQuery types and documents. Updated GetCoreSettingsQuery to include customization.activationCode structure.
Web Summary & Next Steps Components web/src/components/Onboarding/steps/OnboardingSummaryStep.vue, web/src/components/Onboarding/steps/OnboardingNextStepsStep.vue	Added internal boot summary display with Pool, Slots, Boot Reserved, BIOS update, and Devices. Integrated submitInternalBootCreation into apply flow. Extended NextStepsStep with reboot button logic triggered by internal boot success.
Web Import Formatting web/src/composables/gql/index.ts	Minor formatting: converted export statement quotes from double to single. No functional changes.
Documentation docs/onboarding-internal-boot-port-differences.md	New documentation file detailing non-1:1 behavioral differences between onboarding internal boot port and webgui implementation across five areas: data source, device labeling, dialog behavior, reboot flow, and visibility source.
Web Test Infrastructure web/__test__/components/Onboarding/OnboardingModal.test.ts, web/__test__/components/Onboarding/OnboardingSummaryStep.test.ts	Extended mocking and test scenarios for internal boot step. Added internalBootVisibilityResult mock, isPartnerBuild flag, internal boot selection state, and assertions for visibility and submission flows. Tests cover regular builds, partner builds, and disabled boot transfer scenarios.

Sequence Diagram(s)

sequenceDiagram
    actor User
    participant Modal as OnboardingModal
    participant InternalBootStep as InternalBootStep
    participant GraphQL as Apollo<br/>(GraphQL)
    participant API as Server
    participant Store as DraftStore

    User->>Modal: Navigate to Internal Boot
    Modal->>GraphQL: GET_INTERNAL_BOOT_CONTEXT_QUERY
    GraphQL->>API: Fetch array, vars, shares, disks
    API-->>GraphQL: Return boot context
    GraphQL-->>InternalBootStep: Provide context data
    
    InternalBootStep->>Store: Load previous selection
    User->>InternalBootStep: Configure pool, devices, boot size
    InternalBootStep->>InternalBootStep: Validate form
    
    User->>InternalBootStep: Submit (Next)
    InternalBootStep->>Store: setInternalBootSelection()
    InternalBootStep->>Modal: onComplete()
    
    Modal->>Modal: Proceed to Summary step
    User->>Modal: Review & Apply
    Modal->>API: submitInternalBootCreation()
    Note over API: POST to mkbootpool.php
    API-->>Modal: Creation response
    
    Modal->>Store: setInternalBootApplySucceeded(true)
    Modal->>Modal: Show reboot button
    User->>Modal: Reboot
    Modal->>API: submitInternalBootReboot()
    Note over API: POST to Boot.php
    API-->>User: System reboots

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~50 minutes

Poem

🐰 A boot in the making, our feature takes flight,
Pools now can boot up, configured just right!
From forms to the servers, the disks dance with glee,
Internal boot magic, as smooth as can be! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Feat/onboarding internal boot' clearly describes the primary feature being added—internal boot functionality for the onboarding flow. It aligns with the extensive changes across API types, GraphQL schemas, UI components, and state management related to internal boot setup.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/onboarding-internal-boot

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

In general, to fix inefficient regular expressions, remove ambiguous quantified subpatterns—especially something like (X*Y)* where characters can be consumed by either X* or Y—or rewrite them into simpler, unambiguous expressions. This usually means collapsing nested quantified groups, avoiding overlapping character classes in successive tokens, or adding explicit boundaries.

Here, the current regex is:

const poolNamePattern = /^[a-z]([a-z0-9~._-]*[a-z_-])*$/;

Semantically, this means:

• Start with a lowercase letter.
• Then, repeat zero or more “segments”, each consisting of:
  • zero or more allowed characters [a-z0-9~._-]*
  • followed by a final character [a-z_-].

This is equivalent to: “start with a letter, then any number of allowed characters, but do not end with a digit or ~.”. We can express this more simply and without nested ambiguous quantifiers as:

^[a-z][a-z0-9~._-]*[a-z_-]$

This form has only simple quantifiers on character classes and no nested repetition, so backtracking is linear. It still enforces:

• First char: [a-z] (lowercase letter).
• Middle: any number (possibly zero) of allowed characters.
• Last char: [a-z_-] (no trailing digit, ~, or .).

To preserve current semantics exactly, we must also accept 2‑character names like aa and reject 1‑character names like a (because the original pattern requires at least one repetition of ([a-z0-9~._-]*[a-z_-])). If the original behavior is intended, we need to maintain “length ≥ 2”. For clarity and to keep the engine’s work simple, we can write:

^[a-z][a-z0-9~._-]*[a-z_-]$

This already ensures a minimum length of 2 because there are two mandatory characters (first and last). Given the original pattern, this is behaviorally equivalent for all strings that fit the alphabet—they all must have at least two characters to match.

Therefore, in web/src/components/Onboarding/steps/OnboardingInternalBootStep.vue, around line 454, replace the existing poolNamePattern definition with the simplified, unambiguous regex:

const poolNamePattern = /^[a-z][a-z0-9~._-]*[a-z_-]$/;

No extra imports or helper methods are needed; we only change this one line.

[github-actions]

This plugin has been deployed to Cloudflare R2 and is available for testing.
Download it at this URL:

https://preview.dl.unraid.net/unraid-api/tag/PR1881/dynamix.unraid.net.plg

[codecov]

Codecov Report

❌ Patch coverage is 26.68622% with 750 lines in your changes missing coverage. Please review.
✅ Project coverage is 47.75%. Comparing base (15bd747) to head (4bf525b).
⚠️ Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
...ts/Onboarding/steps/OnboardingInternalBootStep.vue	0.16%	591 Missing ⚠️
...src/components/Onboarding/store/onboardingDraft.ts	0.00%	62 Missing ⚠️
.../components/Onboarding/composables/internalBoot.ts	74.31%	28 Missing ⚠️
...nents/Onboarding/steps/OnboardingNextStepsStep.vue	0.00%	16 Missing ⚠️
.../unraid-api/graph/resolvers/disks/disks.service.ts	75.80%	15 Missing ⚠️
...rc/unraid-api/graph/resolvers/disks/disks.model.ts	25.00%	9 Missing ⚠️
...ponents/Onboarding/steps/OnboardingSummaryStep.vue	90.72%	9 Missing ⚠️
web/src/components/Onboarding/stepRegistry.ts	0.00%	7 Missing ⚠️
.../src/unraid-api/graph/resolvers/vars/vars.model.ts	0.00%	6 Missing ⚠️
web/src/components/Onboarding/OnboardingModal.vue	91.30%	4 Missing ⚠️
... and 2 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1881      +/-   ##
==========================================
- Coverage   48.06%   47.75%   -0.32%     
==========================================
  Files        1002     1006       +4     
  Lines       66511    67495     +984     
  Branches     6672     6727      +55     
==========================================
+ Hits        31968    32229     +261     
- Misses      34422    35144     +722     
- Partials      121      122       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[coderabbitai]

Actionable comments posted: 5

🧹 Nitpick comments (3)

web/src/components/Onboarding/OnboardingSteps.vue (1)

10-17: Consider centralizing StepId in a shared type.

Lines [10-17] still duplicate step IDs in this component. Exporting a single StepId type from a shared onboarding module would reduce drift risk as steps evolve.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web/src/components/Onboarding/OnboardingSteps.vue` around lines 10 - 17, This
file defines a local StepId union type that duplicates onboarding step IDs;
remove the local StepId declaration in OnboardingSteps.vue and import a single
exported StepId from a shared onboarding types/module (e.g., export StepId from
a new/shared onboarding types file), then update all references in this
component (and any other components) to use the imported StepId type; ensure the
shared module exports the same union values and update any usages of
'OVERVIEW'|'CONFIGURE_SETTINGS' etc. to the centralized StepId to prevent drift.

web/src/components/Onboarding/steps/OnboardingNextStepsStep.vue (2)

83-90: Consider adding error handling for the reboot submission.

submitInternalBootReboot() is called without awaiting or handling potential errors. If the reboot request fails, the user has no feedback.

♻️ Suggested approach

-const handlePrimaryAction = () => {
+const handlePrimaryAction = async () => {
   if (showRebootButton.value) {
-    submitInternalBootReboot();
-    return;
+    try {
+      await submitInternalBootReboot();
+    } catch (error) {
+      console.error('Reboot request failed:', error);
+    }
+    return;
   }

   props.onComplete();
 };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web/src/components/Onboarding/steps/OnboardingNextStepsStep.vue` around lines
83 - 90, handlePrimaryAction calls submitInternalBootReboot() without awaiting
or handling failures, so add async error handling: make handlePrimaryAction
async, await submitInternalBootReboot(), wrap the call in try/catch, show user
feedback on error (e.g., set a local error state or call an existing
notification method) and only call props.onComplete() on success; also consider
disabling the primary button or showing a loading state while awaiting
submitInternalBootReboot() to prevent duplicate submissions.

---

52-54: Hardcoded "Reboot" string should use i18n.

The primaryButtonText uses a hardcoded 'Reboot' string while other text uses t() for translation. This creates an inconsistency for localized builds.

♻️ Suggested fix

 const primaryButtonText = computed(() =>
-  showRebootButton.value ? 'Reboot' : t('onboarding.nextSteps.continueToDashboard')
+  showRebootButton.value ? t('common.reboot', 'Reboot') : t('onboarding.nextSteps.continueToDashboard')
 );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web/src/components/Onboarding/steps/OnboardingNextStepsStep.vue` around lines
52 - 54, primaryButtonText uses a hardcoded 'Reboot' instead of the i18n helper;
update the computed to call t() for the reboot label (e.g.,
t('onboarding.nextSteps.reboot')) when showRebootButton.value is true, and add
the corresponding translation key/value to your locale files; reference
primaryButtonText and showRebootButton to locate and change the conditional, and
ensure existing usages of t('onboarding.nextSteps.continueToDashboard') remain
unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@web/src/components/Onboarding/composables/internalBoot.ts`:
- Around line 46-56: The code is unsafely casting JSON.parse results to
MkbootpoolResponsePayload and coercing parsed.ok with Boolean(), bypassing
runtime validation and mis-handling string "false"; instead parse into unknown
(no "as" cast), implement a runtime type guard that checks required fields and
their types (e.g., verify the parsed object has the expected properties for
MkbootpoolResponsePayload), apply that guard both after JSON.parse(trimmed) and
after JSON.parse(trimmed.slice(firstBrace, lastBrace + 1)), and for parsed.ok
normalize it explicitly (if typeof ok === 'boolean' use it, else if typeof ok
=== 'string' accept only 'true'/'false' and convert accordingly), returning null
if validation fails; remove all "as MkbootpoolResponsePayload" casts and replace
them with validated, typed returns using the new type guard.
- Around line 85-119: The code processes the fetch result without checking HTTP
success and uses unsafe casts; update the logic to require response.ok when
deciding success (e.g., return ok: response.ok && parsed?.ok === true instead of
Boolean(parsed.ok)) and modify the parsing flow to remove "as
MkbootpoolResponsePayload" casts by moving JSON.parse/validation into a proper
type-guard or validator inside parseMkbootpoolPayload (ensure
parseMkbootpoolPayload returns a typed union or null after validating required
fields like ok, code, output) so you no longer need to cast parsed values before
using them.

In `@web/src/components/Onboarding/stepRegistry.ts`:
- Around line 38-42: INTERNAL_BOOT in the stepRegistry uses hardcoded English
strings for titleKey and descriptionKey; replace them with i18n keys (e.g., set
titleKey to a key like 'onboarding.internalBoot.title' and descriptionKey to
'onboarding.internalBoot.description') to match the project's localization
pattern used by other steps, and add the corresponding entries to the locale
resource files so the keys resolve at runtime.

In `@web/src/components/Onboarding/steps/OnboardingInternalBootStep.vue`:
- Around line 454-458: The regex assigned to poolNamePattern (used to validate
normalizedPoolName) contains nested quantifiers which can lead to ReDoS; replace
the single complex pattern with a safer two-step validation: first use a simple
allowed-character pattern (e.g., ensure it starts with a lowercase letter and
only contains allowed chars) and then separately check structural rules (e.g.,
does not end or start with a digit, disallow consecutive special characters, or
other constraints). Update the validation logic where poolNamePattern is tested
and set formError.value accordingly so the tests use the new checks instead of
the vulnerable nested-quantifier regex.

In `@web/src/composables/gql/index.ts`:
- Around line 1-2: The re-exports in web/src/composables/gql/index.ts use
extensionless relative paths which breaks ESM conventions; update the two export
statements (export * from './fragment-masking' and export * from './gql') to
include the .js extension (export * from './fragment-masking.js' and export *
from './gql.js') so they match the project's ESM style and other modules like
web/src/utils/authorizationLink.ts.

---

Nitpick comments:
In `@web/src/components/Onboarding/OnboardingSteps.vue`:
- Around line 10-17: This file defines a local StepId union type that duplicates
onboarding step IDs; remove the local StepId declaration in OnboardingSteps.vue
and import a single exported StepId from a shared onboarding types/module (e.g.,
export StepId from a new/shared onboarding types file), then update all
references in this component (and any other components) to use the imported
StepId type; ensure the shared module exports the same union values and update
any usages of 'OVERVIEW'|'CONFIGURE_SETTINGS' etc. to the centralized StepId to
prevent drift.

In `@web/src/components/Onboarding/steps/OnboardingNextStepsStep.vue`:
- Around line 83-90: handlePrimaryAction calls submitInternalBootReboot()
without awaiting or handling failures, so add async error handling: make
handlePrimaryAction async, await submitInternalBootReboot(), wrap the call in
try/catch, show user feedback on error (e.g., set a local error state or call an
existing notification method) and only call props.onComplete() on success; also
consider disabling the primary button or showing a loading state while awaiting
submitInternalBootReboot() to prevent duplicate submissions.
- Around line 52-54: primaryButtonText uses a hardcoded 'Reboot' instead of the
i18n helper; update the computed to call t() for the reboot label (e.g.,
t('onboarding.nextSteps.reboot')) when showRebootButton.value is true, and add
the corresponding translation key/value to your locale files; reference
primaryButtonText and showRebootButton to locate and change the conditional, and
ensure existing usages of t('onboarding.nextSteps.continueToDashboard') remain
unchanged.

---

ℹ️ Review info

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between aaa0372 and 4bf525b.

⛔ Files ignored due to path filters (1)

• api/src/unraid-api/cli/generated/graphql.ts is excluded by !**/generated/**

📒 Files selected for processing (27)

• api/generated-schema.graphql
• api/src/__test__/store/modules/emhttp.test.ts
• api/src/__test__/store/state-parsers/var.test.ts
• api/src/core/types/states/var.ts
• api/src/store/state-parsers/var.ts
• api/src/unraid-api/graph/resolvers/disks/disks.model.ts
• api/src/unraid-api/graph/resolvers/disks/disks.service.spec.ts
• api/src/unraid-api/graph/resolvers/disks/disks.service.ts
• api/src/unraid-api/graph/resolvers/vars/vars.model.ts
• docs/onboarding-internal-boot-port-differences.md
• web/__test__/components/Onboarding/OnboardingModal.test.ts
• web/__test__/components/Onboarding/OnboardingSummaryStep.test.ts
• web/__test__/components/Onboarding/internalBoot.test.ts
• web/components.d.ts
• web/src/components/Onboarding/OnboardingModal.vue
• web/src/components/Onboarding/OnboardingSteps.vue
• web/src/components/Onboarding/composables/internalBoot.ts
• web/src/components/Onboarding/graphql/getInternalBootContext.query.ts
• web/src/components/Onboarding/graphql/getInternalBootStepVisibility.query.ts
• web/src/components/Onboarding/stepRegistry.ts
• web/src/components/Onboarding/steps/OnboardingInternalBootStep.vue
• web/src/components/Onboarding/steps/OnboardingNextStepsStep.vue
• web/src/components/Onboarding/steps/OnboardingSummaryStep.vue
• web/src/components/Onboarding/store/onboardingDraft.ts
• web/src/composables/gql/gql.ts
• web/src/composables/gql/graphql.ts
• web/src/composables/gql/index.ts

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# First, let's find and read the file to see the actual code
file_path="web/src/components/Onboarding/composables/internalBoot.ts"

if [ -f "$file_path" ]; then
  echo "=== File exists: $file_path ==="
  echo "=== Full file content ==="
  cat -n "$file_path"
else
  echo "File not found at $file_path"
  # Try to find it with fd
  echo "=== Searching for internalBoot.ts ==="
  fd -a 'internalBoot\.ts$'
fi

Repository: unraid/api

Length of output: 4838

---

Avoid unsafe parse casts and truthy coercion for ok.

Lines 46 and 55 use as MkbootpoolResponsePayload which bypasses TypeScript's type system without runtime shape validation. Additionally, line 103's Boolean(parsed.ok) mishandles string values (e.g., "false" becomes true). Per coding guidelines, avoid casting; prefer proper typing from the start.

Proposed fix

 interface MkbootpoolResponsePayload {
   ok?: boolean;
   code?: number;
   output?: string;
 }
+
+const isMkbootpoolResponsePayload = (value: unknown): value is MkbootpoolResponsePayload => {
+  if (!value || typeof value !== 'object') return false;
+  const v = value as { ok?: unknown; code?: unknown; output?: unknown };
+  return (
+    (v.ok === undefined || typeof v.ok === 'boolean') &&
+    (v.code === undefined || typeof v.code === 'number') &&
+    (v.output === undefined || typeof v.output === 'string')
+  );
+};
@@
   try {
-    return JSON.parse(trimmed) as MkbootpoolResponsePayload;
+    const parsed: unknown = JSON.parse(trimmed);
+    return isMkbootpoolResponsePayload(parsed) ? parsed : null;
   } catch {
@@
     try {
-      return JSON.parse(trimmed.slice(firstBrace, lastBrace + 1)) as MkbootpoolResponsePayload;
+      const parsed: unknown = JSON.parse(trimmed.slice(firstBrace, lastBrace + 1));
+      return isMkbootpoolResponsePayload(parsed) ? parsed : null;
     } catch {
       return null;
     }
@@
-      ok: Boolean(parsed.ok),
+      ok: parsed.ok === true,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web/src/components/Onboarding/composables/internalBoot.ts` around lines 46 -
56, The code is unsafely casting JSON.parse results to MkbootpoolResponsePayload
and coercing parsed.ok with Boolean(), bypassing runtime validation and
mis-handling string "false"; instead parse into unknown (no "as" cast),
implement a runtime type guard that checks required fields and their types
(e.g., verify the parsed object has the expected properties for
MkbootpoolResponsePayload), apply that guard both after JSON.parse(trimmed) and
after JSON.parse(trimmed.slice(firstBrace, lastBrace + 1)), and for parsed.ok
normalize it explicitly (if typeof ok === 'boolean' use it, else if typeof ok
=== 'string' accept only 'true'/'false' and convert accordingly), returning null
if validation fails; remove all "as MkbootpoolResponsePayload" casts and replace
them with validated, typed returns using the new type guard.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find the file
find . -name "internalBoot.ts" -type f

Repository: unraid/api

Length of output: 113

---

🏁 Script executed:

#!/bin/bash
# Read the file to see the full context
cat -n web/src/components/Onboarding/composables/internalBoot.ts

Repository: unraid/api

Length of output: 4733

---

🏁 Script executed:

#!/bin/bash
# Search for the parseMkbootpoolPayload function definition
rg -nP 'function\s+parseMkbootpoolPayload|const\s+parseMkbootpoolPayload' -A10 web/src/components/Onboarding/composables/

Repository: unraid/api

Length of output: 1064

---

🏁 Script executed:

#!/bin/bash
# Find all call sites of submitInternalBootCreation
rg -nP '\bsubmitInternalBootCreation\s*\(' --type=ts --type=tsx

Repository: unraid/api

Length of output: 81

---

🏁 Script executed:

#!/bin/bash
# Check the type definitions for InternalBootSubmitResult
rg -nP 'interface\s+InternalBootSubmitResult|type\s+InternalBootSubmitResult' -A5 web/src/components/Onboarding/

Repository: unraid/api

Length of output: 516

---

🏁 Script executed:

#!/bin/bash
# Find all call sites - retry without tsx type issue
rg -nP '\bsubmitInternalBootCreation\s*\(' -A5 -B2 --type=ts

Repository: unraid/api

Length of output: 729

---

🏁 Script executed:

#!/bin/bash
# Also check for any imports of this function
rg -nP 'submitInternalBootCreation' --type=ts -B2

Repository: unraid/api

Length of output: 2615

---

🏁 Script executed:

#!/bin/bash
# Check if response.ok is checked anywhere in the codebase
rg -nP 'response\.ok' web/src/components/Onboarding/

Repository: unraid/api

Length of output: 36

---

🏁 Script executed:

#!/bin/bash
# Examine the test file to see how the result is used
cat -n web/__test__/components/Onboarding/internalBoot.test.ts

Repository: unraid/api

Length of output: 3297

---

🏁 Script executed:

#!/bin/bash
# Check the OnboardingSummaryStep component for actual usage
rg -nP 'submitInternalBootCreation' web/src/components/Onboarding/ -B3 -A8

Repository: unraid/api

Length of output: 3846

---

🏁 Script executed:

#!/bin/bash
# Check if response.ok is used anywhere in response handling
rg -nP 'response\.(ok|status)' web/src/components/Onboarding/

Repository: unraid/api

Length of output: 275

---

🏁 Script executed:

#!/bin/bash
# Search entire codebase for any other calls to submitInternalBootCreation outside Onboarding dir
rg -nP 'submitInternalBootCreation' --type=ts

Repository: unraid/api

Length of output: 1091

---

🏁 Script executed:

#!/bin/bash
# Check context around the call in OnboardingSummaryStep to confirm try-catch is present
sed -n '655,680p' web/src/components/Onboarding/steps/OnboardingSummaryStep.vue

Repository: unraid/api

Length of output: 912

---

🏁 Script executed:

#!/bin/bash
# Check the complete try-catch block and error handling context
sed -n '655,695p' web/src/components/Onboarding/steps/OnboardingSummaryStep.vue

Repository: unraid/api

Length of output: 1421

---

Check response.ok before processing response body and remove unnecessary type casts.

The function doesn't check response.ok before parsing the response, allowing non-2xx HTTP responses with valid JSON bodies to return ok: true. Additionally, lines 46 and 55 use as MkbootpoolResponsePayload casts, violating the typing guideline to avoid casting.

Recommended fixes:

1. Check response.ok when determining success (line 103 should use ok: response.ok && parsed.ok === true instead of Boolean(parsed.ok))
2. Replace JSON.parse(trimmed) as MkbootpoolResponsePayload with proper type guards or validation to eliminate casts per coding guidelines

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web/src/components/Onboarding/composables/internalBoot.ts` around lines 85 -
119, The code processes the fetch result without checking HTTP success and uses
unsafe casts; update the logic to require response.ok when deciding success
(e.g., return ok: response.ok && parsed?.ok === true instead of
Boolean(parsed.ok)) and modify the parsing flow to remove "as
MkbootpoolResponsePayload" casts by moving JSON.parse/validation into a proper
type-guard or validator inside parseMkbootpoolPayload (ensure
parseMkbootpoolPayload returns a typed union or null after validating required
fields like ok, code, output) so you no longer need to cast parsed values before
using them.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Hardcoded strings should use i18n keys for consistency.

Other steps use localization key patterns (e.g., 'onboarding.coreSettings.title'), but INTERNAL_BOOT uses hardcoded English strings. This will prevent localization of the internal boot step.

Suggested fix using i18n keys

   INTERNAL_BOOT: {
-    titleKey: 'Internal Boot',
-    descriptionKey: 'Configure bootable pool',
+    titleKey: 'onboarding.internalBoot.title',
+    descriptionKey: 'onboarding.internalBoot.description',
     icon: 'i-heroicons-circle-stack',
   },

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	INTERNAL_BOOT: {
	titleKey: 'Internal Boot',
	descriptionKey: 'Configure bootable pool',
	icon: 'i-heroicons-circle-stack',
	},
	INTERNAL_BOOT: {
	titleKey: 'onboarding.internalBoot.title',
	descriptionKey: 'onboarding.internalBoot.description',
	icon: 'i-heroicons-circle-stack',
	},

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web/src/components/Onboarding/stepRegistry.ts` around lines 38 - 42,
INTERNAL_BOOT in the stepRegistry uses hardcoded English strings for titleKey
and descriptionKey; replace them with i18n keys (e.g., set titleKey to a key
like 'onboarding.internalBoot.title' and descriptionKey to
'onboarding.internalBoot.description') to match the project's localization
pattern used by other steps, and add the corresponding entries to the locale
resource files so the keys resolve at runtime.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Potential ReDoS vulnerability in pool name regex.

The pattern ([a-z0-9~._-]*[a-z_-])* can cause exponential backtracking on inputs like "a" + "-".repeat(30). The nested quantifiers create overlapping match possibilities.

🔒 Suggested fix with a safer pattern

-  const poolNamePattern = /^[a-z]([a-z0-9~._-]*[a-z_-])*$/;
+  // Validates: starts with lowercase letter, contains allowed chars, doesn't end with digit
+  const poolNamePattern = /^[a-z][a-z0-9~._-]*[a-z_-]$|^[a-z]$/;
   if (!poolNamePattern.test(normalizedPoolName)) {

Alternatively, if the intent is to disallow consecutive special characters or enforce specific structure, consider validating in multiple steps:

// Check allowed characters first, then validate structure
const hasValidChars = /^[a-z][a-z0-9~._-]*$/.test(normalizedPoolName);
const endsWithDigit = /\d$/.test(normalizedPoolName);
if (!hasValidChars || endsWithDigit) {
  formError.value = '...';
  return null;
}

🧰 Tools

🪛 GitHub Check: CodeQL

[failure] 454-454: Inefficient regular expression
This part of the regular expression may cause exponential backtracking on strings starting with 'a' and containing many repetitions of '-'.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web/src/components/Onboarding/steps/OnboardingInternalBootStep.vue` around
lines 454 - 458, The regex assigned to poolNamePattern (used to validate
normalizedPoolName) contains nested quantifiers which can lead to ReDoS; replace
the single complex pattern with a safer two-step validation: first use a simple
allowed-character pattern (e.g., ensure it starts with a lowercase letter and
only contains allowed chars) and then separately check structural rules (e.g.,
does not end or start with a digit, disallow consecutive special characters, or
other constraints). Update the validation logic where poolNamePattern is tested
and set formError.value accordingly so the tests use the new checks instead of
the vulnerable nested-quantifier regex.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

# First, locate and read the file in question
find . -name "index.ts" -path "*/composables/gql/*" -type f

Repository: unraid/api

Length of output: 119

---

🏁 Script executed:

# Also check for the referenced files
find . -path "*/composables/gql/*" -type f

Repository: unraid/api

Length of output: 377

---

🏁 Script executed:

# Search for similar re-export patterns in the web directory
rg "export \* from" web/ --type ts -A 0 -B 0 | head -30

Repository: unraid/api

Length of output: 372

---

🏁 Script executed:

cat -n web/src/composables/gql/index.ts

Repository: unraid/api

Length of output: 126

---

🏁 Script executed:

# Check other re-export patterns in web/src to understand consistency
rg "export \* from" web/src --type ts -B 0 -A 0 | sort | uniq -c

Repository: unraid/api

Length of output: 279

---

🏁 Script executed:

# Check if there's any build or transpilation config that might affect this
find . -name "tsconfig.json" -o -name "nuxt.config.ts" -o -name "vite.config.ts" | head -5 | xargs cat 2>/dev/null

Repository: unraid/api

Length of output: 11785

---

Add .js extensions to re-exports for ESM compatibility.

Lines 1-2 use extensionless relative paths, which violates the project's ESM convention. Other files in the codebase (e.g., web/src/utils/authorizationLink.ts) consistently use .js extensions in re-exports.

Suggested fix

-export * from './fragment-masking';
-export * from './gql';
+export * from './fragment-masking.js';
+export * from './gql.js';

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	export * from './fragment-masking';
	export * from './gql';
	export * from './fragment-masking.js';
	export * from './gql.js';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web/src/composables/gql/index.ts` around lines 1 - 2, The re-exports in
web/src/composables/gql/index.ts use extensionless relative paths which breaks
ESM conventions; update the two export statements (export * from
'./fragment-masking' and export * from './gql') to include the .js extension
(export * from './fragment-masking.js' and export * from './gql.js') so they
match the project's ESM style and other modules like
web/src/utils/authorizationLink.ts.