host calls wip #455

tomusdrw · 2025-11-29T22:36:47Z

Handle host calls.
Initial version of host calls handling.

netlify · 2025-11-29T22:36:53Z

✅ Deploy Preview for pvm-debugger ready!

Name	Link
🔨 Latest commit	`37ebdf7`
🔍 Latest deploy log	https://app.netlify.com/projects/pvm-debugger/deploys/692ef8baace89b0009ac2b9f
😎 Deploy Preview	https://deploy-preview-455--pvm-debugger.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

coderabbitai · 2025-11-29T22:36:53Z

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

📝 Walkthrough

Walkthrough

This pull request introduces a comprehensive host call debugging system to the PVM debugger. It adds a HostCallDialog component with specialized handlers for different host call types (Gas, Fetch, Info, Log, Provide, Read, Transfer, Write, Yield), supporting utilities for memory simulation and state management, and new web worker command handlers. The @typeberry/lib dependency is also updated.

Changes

Cohort / File(s)	Summary
Dependencies `package.json`	Updated `@typeberry/lib` from ^0.4.1-ea3c83c to ^0.4.1-3923458
Host Call Dialog—Core `src/App.tsx`, `src/components/HostCallDialog/index.tsx`, `src/components/HostCallDialog/DefaultHostCallContent.tsx`, `src/components/HostCallDialog/MemoryEditor.tsx`	New HostCallDialog component and supporting base UI components for rendering host call state, memory editor, and generic host call content display
Host Call Handlers `src/components/HostCallDialog/handlers/GasHostCall.tsx`, `src/components/HostCallDialog/handlers/FetchHostCall.tsx`, `src/components/HostCallDialog/handlers/InfoHostCall.tsx`, `src/components/HostCallDialog/handlers/LogHostCall.tsx`, `src/components/HostCallDialog/handlers/ProvideHostCall.tsx`, `src/components/HostCallDialog/handlers/ReadHostCall.tsx`, `src/components/HostCallDialog/handlers/TransferHostCall.tsx`, `src/components/HostCallDialog/handlers/WriteHostCall.tsx`, `src/components/HostCallDialog/handlers/YieldHostCall.tsx`	Nine specialized host call handlers simulating and rendering UI for each host call type
Host Call Handler Infrastructure `src/components/HostCallDialog/handlers/types.ts`, `src/components/HostCallDialog/handlers/index.ts`, `src/components/HostCallDialog/handlers/HostCallActionButtons.tsx`, `src/components/HostCallDialog/handlers/hostCallUtils.ts`, `src/components/HostCallDialog/handlers/storageManager.ts`	Types, registry, utilities (MockMemory, MockGasCounter, hex/bytes conversion), storage manager, and action buttons for host call handlers
Web Worker Commands `src/packages/web-worker/command-handlers/set-state.ts`, `src/packages/web-worker/command-handlers/set-memory.ts`, `src/packages/web-worker/command-handlers/index.ts`, `src/packages/web-worker/command-handlers/memory.ts`, `src/packages/web-worker/types.ts`, `src/packages/web-worker/worker.ts`	New SET_STATE and SET_MEMORY command handlers for web worker; added error context to memory command diagnostics
Redux Store Updates `src/store/workers/workersSlice.ts`, `src/store/debugger/debuggerSlice.ts`	New thunks (readMemoryRange, resumeAfterHostCall), host call state management, and revised handleHostCall fallback to open dialog instead of error
Type Definitions & Constants `src/types/pvm.ts`	New exported constants DEFAULT_REGS and DEFAULT_GAS
Existing Component Integration `src/components/DebuggerSettings/Content.tsx`, `src/components/ProgramLoader/Examples.tsx`, `src/components/ProgramLoader/Loader.tsx`, `src/components/ProgramLoader/examplePrograms.ts`, `src/components/ProgramLoader/loadingUtils.ts`, `src/components/Instructions/BasicBlocks/CollapsibleInstructionsTable.tsx`, `src/components/Registers/index.tsx`, `src/pages/ProgramLoader.tsx`, `src/hooks/useDebuggerActions.ts`	Updated to integrate host call system: blob-based SPI args handling, storage manager initialization, default gas usage, error handling in args decoder, and register status display enhancement

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Each host call handler requires independent logic review; handlers differ significantly in their execution patterns (Gas uses mocked Gas, Fetch constructs fake memory, Info parses form inputs, etc.)
HostCallContext and utilities (MockMemory, MockGasCounter, hex/bytes conversions) need careful validation for correctness
Redux thunk implementations (readMemoryRange, resumeAfterHostCall) coordinate multiple operations and state transitions
MemoryEditor component with per-byte editing and hex input validation
Web worker command handlers and type integration with existing worker infrastructure
Integration points across multiple existing components (DebuggerSettings, ProgramLoader, Registers, etc.) need verification for consistency

Possibly related PRs

PR #451: Both PRs modify SPI loading, ProgramLoader, default constants (DEFAULT_GAS, DEFAULT_REGS), web worker initialization, and @typeberry/lib versioning, indicating a closely related feature implementation.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 53.33% which is insufficient. The required threshold is 80.00%.	You can run `@coderabbitai generate docstrings` to improve docstring coverage.
Title check	❓ Inconclusive	The title 'host calls wip' is vague and uses non-standard abbreviations ('wip' likely meaning 'work in progress'), making it unclear without context.	Replace with a more descriptive title like 'Add host call dialog and handlers' or 'Implement host call UI and execution framework'.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description mentions 'Handle host calls' and 'Initial version of host calls handling', which aligns with the extensive host call infrastructure added throughout the changeset.

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

coderabbitai

Actionable comments posted: 7

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

src/components/ProgramLoader/examplePrograms.ts (2)
54-54: Inconsistent gas value: Use DEFAULT_GAS or document the reason.

The gameOfLife program uses a hardcoded gas value of 10_000_000n, while other programs (fibonacci, add, storeU16, empty) now use DEFAULT_GAS. This inconsistency undermines the centralization effort. If this program requires more gas, consider documenting why with a comment.

Apply this diff to use the default:
-    gas: 10_000_000n,
+    gas: DEFAULT_GAS,
Or document the special requirement:
-    gas: 10_000_000n,
+    // Game of Life requires more gas due to complex simulation
+    gas: 10_000_000n,
63-63: Inconsistent gas value: Use DEFAULT_GAS or document the reason.

The branch program uses a hardcoded gas value of 10n, while other programs now use DEFAULT_GAS. This inconsistency undermines the centralization effort. If this minimal gas is intentional for testing purposes, consider documenting it.

Apply this diff to use the default:
-    gas: 10n,
+    gas: DEFAULT_GAS,
Or document the special requirement:
-    gas: 10n,
+    // Minimal gas for testing branch behavior
+    gas: 10n,

🧹 Nitpick comments (32)

src/components/Registers/index.tsx (1)

14-14: Host status formatter: enum key casing and multi‑worker exitArg handling

The new formatter logic looks good for enriching the status label, but there are two potential pitfalls worth checking:

Enum key casing: statusValue === Status.HOST assumes a HOST member. If your Status type/enum uses names like Host (as suggested by the worker Status mapping), this will either not compile or always be false, and displayText/extra classes will never be applied for host status. Please confirm the actual Status definition and align the member name accordingly.

Using only workers[0]?.exitArg: You’re always reading exitArg from the first worker, both for the main cell and the per‑worker tooltip rows (since formatter closes over workers and formatValueToDisplay applies it to each worker’s value). If multiple workers can have different exitArg values, this will misrepresent them in the tooltip and in the summary. Consider deriving exitArg from the worker whose value you’re formatting (or from a selected/active worker in state) instead of hard‑coding index 0.

Also applies to: 175-193
src/packages/web-worker/command-handlers/set-memory.ts (1)
1-35: SetMemory handler shape looks good; consider awaiting setMemory

The handler’s null-check and structured CommandStatus responses look consistent with other worker commands. Given runSetMemory is async, it would be safer to await the PVM call so any async failures are caught by this try/catch:
-  try {
-    // Use the PVM's setMemory API to write data
-    pvm.setMemory(address, data);
+  try {
+    // Use the PVM's setMemory API to write data
+    await pvm.setMemory(address, data);
This is a no-op if setMemory is currently synchronous but future‑proofs the handler if the API becomes async. As per coding guidelines, this keeps the worker RPC behavior predictable for WASM-facing consumers.
src/components/ProgramLoader/Examples.tsx (1)

9-9: SPI args integration into Doom/GoL example loads looks correct

Reading spiArgs from state.debugger.spiArgs and threading it into loadFileFromUint8Array for the Doom and GoL examples brings these flows in line with the rest of the SPI-loading pipeline, and should work well with the spiArgsAsBytes handling inside the loader.

As a minor hardening step, you might eventually want to pass a well-typed initialState object instead of {} in these two calls so that, if the detection logic ever falls back to the generic PVM path, it doesn’t rely on an empty object.

Also applies to: 14-14, 59-60, 79-80

src/components/Instructions/BasicBlocks/CollapsibleInstructionsTable.tsx (1)

23-23: Defensive ArgsDecoder initialization avoids crashes in widestItemValue

Wrapping decodeAndGetArgsDecoder(program) in a try/catch here and falling back to "" if decoding fails is a sensible way to prevent broken/partial programs from crashing the instructions table while computing column widths. If you find it useful during debugging, you could also log the decode failure once inside the catch, but the current behavior is acceptable and keeps the UI resilient.

Also applies to: 169-174
src/components/HostCallDialog/handlers/storageManager.ts (2)
26-38: Write method behavior is clear but consider edge cases.

The write() method's delete-on-null behavior is well-documented. However, consider:

The return value (previous length) might be unexpected for callers expecting a boolean or void

No validation that value is a valid Uint8Array when non-null

Consider adding a validation check:
  write(key: BytesBlob, value: Uint8Array | null): number | null {
    const keyHex = key.toString();
    const previousValue = this.storage.get(keyHex);
    const previousLength = previousValue ? previousValue.length : null;

    if (value === null) {
      this.storage.delete(keyHex);
    } else {
+     if (!(value instanceof Uint8Array)) {
+       throw new TypeError('Value must be a Uint8Array');
+     }
      this.storage.set(keyHex, new Uint8Array(value));
    }

    return previousLength;
  }
9-61: Consider adding a method to get storage size.

For debugging and monitoring purposes, consider adding a method to get the current storage size (number of entries or total bytes).
/**
 * Get the number of entries in storage.
 */
getSize(): number {
  return this.storage.size;
}

/**
 * Get the total number of bytes stored.
 */
getTotalBytes(): number {
  let total = 0;
  for (const value of this.storage.values()) {
    total += value.length;
  }
  return total;
}
src/packages/web-worker/command-handlers/set-state.ts (1)
17-67: Consider using DEFAULT_REGS for initialization.

The PR introduces DEFAULT_REGS constant in src/types/pvm.ts. Consider whether this handler should support resetting to default values when regs is not provided or is empty.

Example enhancement:
import { DEFAULT_REGS } from "@/types/pvm";

export type SetStateParams = {
  pvm: PvmApiInterface | null;
  regs?: bigint[]; // Make optional
  gas: bigint;
};

// Inside runSetState:
const regsToSet = regs && regs.length === 13 ? regs : DEFAULT_REGS;
src/components/HostCallDialog/handlers/ProvideHostCall.tsx (2)
44-66: Consider extracting common partialState stubs to reduce duplication.

The partialState object is duplicated in both the mount effect and handleResume. The stub methods (transfer, checkPreimageStatus, etc.) are identical. Consider extracting a factory function or base object:
+// At module level or inside component
+const createBasePartialState = (resolvedServiceId: ReturnType<typeof block.tryAsServiceId>): Omit<PartialState, 'providePreimage'> => ({
+  transfer: () => Result.ok(OK),
+  checkPreimageStatus: () => null,
+  requestPreimage: () => Result.ok(OK),
+  forgetPreimage: () => Result.ok(OK),
+  eject: () => Result.ok(OK),
+  newService: () => Result.ok(resolvedServiceId),
+  upgradeService: () => {},
+  updateValidatorsData: () => Result.ok(OK),
+  checkpoint: () => {},
+  updateAuthorizationQueue: () => Result.ok(OK),
+  updatePrivilegedServices: () => Result.ok(OK),
+  yield: () => {},
+});

// Then use:
 const partialState: PartialState = {
+  ...createBasePartialState(resolvedServiceId),
   providePreimage: (service, preimage) => { /* capture logic */ },
-  transfer: () => Result.ok(OK),
-  // ... rest of stubs
 };
Also applies to: 99-113

94-135: Consider extracting memory preloading logic.

The memory preloading pattern (lines 117-122) duplicates lines 72-77. This could be extracted to a helper function for maintainability.

Additionally, the async handleResume sets isExecuting to true but doesn't have cleanup if the component unmounts during execution. This is a minor concern since onResume likely navigates away.
+const preloadPreimageMemory = async (
+  ctx: HostCallContext,
+  regs: bigint[],
+  readMemory: (addr: number, len: number) => Promise<Uint8Array>
+) => {
+  const preimagePointer = Number(regs[8] ?? 0n);
+  const preimageLength = Number(regs[9] ?? 0n);
+  if (preimagePointer > 0 && preimageLength > 0) {
+    const preimageData = await readMemory(preimagePointer, preimageLength);
+    ctx.preloadMemory(preimagePointer, preimageData);
+  }
+};
src/components/HostCallDialog/MemoryEditor.tsx (3)
51-77: onMemoryChange in dependency array may cause spurious reloads.

The onMemoryChange callback is included in the dependency array but isn't used inside the effect. If the parent doesn't memoize this callback, the effect will re-run on every parent render, triggering unnecessary memory fetches.
   useEffect(() => {
     const loadMemory = async () => {
       // ...loading logic
     };
 
     loadMemory();
-  }, [address, length, readMemory, onMemoryChange]);
+  }, [address, length, readMemory]);
115-129: Single-byte edit sends entire buffer; address is view start, not edited byte.

When editing one byte, onMemoryChange receives the view's start address and the entire buffer. If consumers expect per-byte edits (as MemoryEdit suggests), this could cause issues or inefficiencies. Consider sending only the edited byte's address and value.
   const handleByteBlur = useCallback(() => {
     if (editingByte === null || !data || address === null) {
       setEditingByte(null);
       return;
     }
 
     const byteValue = parseInt(editValue || "0", 16);
     if (!isNaN(byteValue) && byteValue >= 0 && byteValue <= 255) {
       const newData = new Uint8Array(data);
       newData[editingByte] = byteValue;
       setData(newData);
-      onMemoryChange?.(address, newData);
+      // Send only the edited byte's address and value
+      onMemoryChange?.(address + editingByte, new Uint8Array([byteValue]));
     }
     setEditingByte(null);
   }, [editingByte, editValue, data, address, onMemoryChange]);
158-176: Labels not associated with inputs via htmlFor/id.

The <label> elements are not programmatically linked to their corresponding inputs, which reduces accessibility for screen readers.
         <div className="flex-1">
-          <label className="text-sm font-medium">Start Address</label>
+          <label htmlFor="memory-start-address" className="text-sm font-medium">Start Address</label>
           <Input
+            id="memory-start-address"
             className="font-mono"
             placeholder="0x1000"
             value={addressInput}
             onChange={(e) => updateAddress(e.target.value)}
             disabled={disabled}
           />
         </div>
         <div className="flex-1">
-          <label className="text-sm font-medium">Length (max {MAX_LENGTH})</label>
+          <label htmlFor="memory-length" className="text-sm font-medium">Length (max {MAX_LENGTH})</label>
           <Input
+            id="memory-length"
             className="font-mono"
             placeholder="256"
             value={lengthInput}
             onChange={(e) => updateLength(e.target.value)}
             disabled={disabled}
           />
         </div>
src/components/HostCallDialog/handlers/FetchHostCall.tsx (1)

91-95: Effect resets input to same constant on every fetchKind change.

The effect resets hexInput to DEFAULT_CONSTANTS whenever fetchKind changes. Since DEFAULT_CONSTANTS is a constants-specific value, this may not be appropriate for other fetch kinds (Entropy, WorkPackage, etc.). Consider using kind-specific defaults or preserving user input.
src/components/HostCallDialog/handlers/InfoHostCall.tsx (3)
48-52: Effect with empty dependency array doesn't reset on dialog reopen.

The effect runs only once on mount. If the component isn't unmounted between dialog opens (e.g., kept in DOM but hidden), the form won't reset. Consider adding hasHostCallOpen or similar dependency, or resetting in a parent-controlled manner.

58-76: No input validation before BigInt/Number parsing.

BigInt(balance) and similar calls will throw SyntaxError if the string is empty or invalid (e.g., "abc"). While the outer try-catch handles this, the error message will be cryptic. Consider validating inputs before parsing or providing field-specific error feedback.
     try {
       // Parse form values
       const codeHashBytes = bytes.BytesBlob.parseBlob(codeHash).raw;
       if (codeHashBytes.length !== 32) {
         throw new Error("Code hash must be exactly 32 bytes");
       }
 
+      // Validate numeric inputs
+      const numericFields = { balance, accumulateMinGas, onTransferMinGas, storageBytes, gratisStorage };
+      for (const [name, value] of Object.entries(numericFields)) {
+        if (!/^\d+$/.test(value.trim())) {
+          throw new Error(`${name} must be a valid non-negative integer`);
+        }
+      }
+
       const serviceInfo = ServiceAccountInfo.create({
90-95: isExecuting not reset on success path.

When onResume succeeds, isExecuting remains true. If the dialog doesn't unmount (e.g., due to an error in the resume flow after this component's try block), the buttons stay disabled permanently.
       const { modifiedRegs, finalGas, memoryEdits } = ctx.getResult();
 
       onResume(mode, modifiedRegs, finalGas, memoryEdits);
+      setIsExecuting(false);
     } catch (e) {
       console.error(e);
       setError(e instanceof Error ? e.message : "Failed to execute info");
       setIsExecuting(false);
     }
src/components/HostCallDialog/index.tsx (1)

112-125: Memory edit merge by address may cause data loss with overlapping ranges.

The merge logic replaces edits at the same start address. If one edit writes bytes at address 0x1000 (length 256) and another at 0x1000 (length 1), the first is replaced entirely. Consider merging by range overlap or using a more sophisticated merge strategy.
src/components/HostCallDialog/handlers/ReadHostCall.tsx (2)
38-92: Potential stale closure risk with onResume in effect dependencies.

The onResume callback is included in the dependency array but the effect is guarded by hasExecuted.current, meaning subsequent identity changes won't trigger re-execution. If onResume changes after the initial execution but before auto-resume completes, the stale callback could be invoked at line 79.

Consider extracting onResume from the dependency array and using a ref to hold the latest callback, or ensure the parent component memoizes onResume with useCallback.

62-69: Consider extracting memory preloading into a helper.

The key memory preloading logic (lines 62-69) is duplicated in handleResume (lines 121-127). For maintainability, consider extracting this into a small helper function within the component.
+  const preloadKeyMemory = useCallback(async (ctx: HostCallContext) => {
+    const keyPointer = Number(regs[8] ?? 0n);
+    const keyLength = Number(regs[9] ?? 0n);
+    if (keyLength > 0) {
+      const keyData = await readMemory(keyPointer, keyLength);
+      ctx.preloadMemory(keyPointer, keyData);
+    }
+  }, [regs, readMemory]);
Also applies to: 121-127
src/components/HostCallDialog/DefaultHostCallContent.tsx (2)
54-56: Consider extracting the gas adjustment constant.

The magic number 10n for gas adjustment should be a named constant to improve readability and maintainability.
+const HOST_CALL_GAS_COST = 10n;
+
 // Set gas to current gas - 10 (as per requirement)
 const currentGas = currentState.gas ?? DEFAULT_GAS;
-const newGas = currentGas > 10n ? currentGas - 10n : 0n;
+const newGas = currentGas > HOST_CALL_GAS_COST ? currentGas - HOST_CALL_GAS_COST : 0n;
62-70: Avoid calling callbacks inside setState updater functions.

Invoking onRegsChange inside the setRegs updater is a side effect within React's state update, which is unconventional and may cause issues with React's batching or concurrent features.
 const handleRegisterChange = (index: number, value: string) => {
   const newValue = stringToNumber(value, BigInt);
-  setRegs((prev) => {
-    const newRegs = [...prev];
-    newRegs[index] = newValue;
-    onRegsChange(newRegs);
-    return newRegs;
-  });
+  const newRegs = [...regs];
+  newRegs[index] = newValue;
+  setRegs(newRegs);
+  onRegsChange(newRegs);
 };
src/components/HostCallDialog/handlers/YieldHostCall.tsx (2)
43-62: Extract duplicate partialState stub into a factory or constant.

The partialState object is defined twice with nearly identical stub implementations. Consider extracting a factory function to reduce duplication and ensure consistency.
+const createPartialStateStub = (
+  resolvedServiceId: ReturnType<typeof block.tryAsServiceId>,
+  onYield?: (hash: OpaqueHash) => void
+): PartialState => ({
+  yield: onYield ?? (() => {}),
+  transfer: () => Result.ok(OK),
+  checkPreimageStatus: () => null,
+  requestPreimage: () => Result.ok(OK),
+  forgetPreimage: () => Result.ok(OK),
+  eject: () => Result.ok(OK),
+  newService: () => Result.ok(resolvedServiceId),
+  upgradeService: () => {},
+  updateValidatorsData: () => Result.ok(OK),
+  checkpoint: () => {},
+  updateAuthorizationQueue: () => Result.ok(OK),
+  updatePrivilegedServices: () => Result.ok(OK),
+  providePreimage: () => Result.ok(OK),
+});
Also applies to: 95-109

44-47: Consider using a shared utility for bytes-to-hex conversion.

The manual hex conversion could be extracted to a utility function in hostCallUtils.ts for consistency with other conversions like hexToAscii.
src/components/HostCallDialog/handlers/TransferHostCall.tsx (2)
45-68: Extract duplicate partialState stub to reduce code duplication.

Similar to other handlers, the partialState object is duplicated between the initial execution and handleResume. This pattern repeats across multiple host call handlers (YieldHostCall, TransferHostCall, etc.) and could benefit from a shared factory function.

Also applies to: 101-115

74-79: Extract MEMO_SIZE as a module-level constant.

The constant is defined inline and duplicated. Moving it to module scope improves clarity.
+const MEMO_SIZE = 128; // TRANSFER_MEMO_BYTES
+
 // Inside execute function:
-const MEMO_SIZE = 128; // TRANSFER_MEMO_BYTES
 if (memoPointer > 0) {
src/components/HostCallDialog/handlers/WriteHostCall.tsx (3)
83-148: Consider extracting duplicate memory preloading logic.

The memory preloading logic for key and value (lines 102-123) is duplicated in handleResume (lines 172-188). Consider extracting this into a shared helper function to reduce code duplication and maintenance burden.
+const preloadKeyValueMemory = async (
+  ctx: HostCallContext,
+  regs: bigint[],
+  readMemory: (address: number, length: number) => Promise<Uint8Array>
+) => {
+  const keyPointer = Number(regs[7] ?? 0n);
+  const keyLength = Number(regs[8] ?? 0n);
+  let keyHex = "";
+  if (keyLength > 0) {
+    const keyData = await readMemory(keyPointer, keyLength);
+    ctx.preloadMemory(keyPointer, keyData);
+    keyHex = bytesToHex(keyData);
+  }
+
+  const valuePointer = regs[9] ?? 0n;
+  const valueLength = Number(regs[10] ?? 0n);
+  const MAX_U64 = 0xffffffffffffffffn;
+  const isDelete = valuePointer >= MAX_U64;
+  let valueHex: string | null = null;
+  if (!isDelete && valueLength > 0) {
+    const valueData = await readMemory(Number(valuePointer), valueLength);
+    ctx.preloadMemory(Number(valuePointer), valueData);
+    valueHex = bytesToHex(valueData);
+  }
+
+  return { keyHex, keyLength, valueHex, valueLength, isDelete };
+};
196-200: Inconsistent error message handling between initial execution and resume.

The initial execution (line 142) extracts the message from the error object, but handleResume (line 198) uses a generic fallback. Consider applying the same detailed error extraction pattern for consistency.
     } catch (e) {
       console.error(e);
-      setError(e instanceof Error ? e.message : "Failed to execute write");
+      const msg = e !== null && typeof e === "object" && "message" in e ? (e as { message: string }).message : "";
+      setError(e instanceof Error ? e.message : `Failed to execute write: ${msg}`);
       setIsExecuting(false);
     }
116-117: Extract MAX_U64 as a module-level constant.

MAX_U64 is defined identically on lines 116 and 183. Move it to the top of the file with the other constants to avoid duplication.
 const { Write, HostCallResult } = jam_host_calls.general;
 const { Result } = utils;
 type AccountsWrite = jam_host_calls.general.AccountsWrite;
+
+// Maximum u64 value - indicates deletion when used as value pointer
+const MAX_U64 = 0xffffffffffffffffn;
Then remove the local declarations on lines 116 and 183.
src/components/HostCallDialog/handlers/hostCallUtils.ts (2)
113-123: Consider validating hex characters in hexToBytes.

The function validates string length but parseInt with radix 16 will return NaN for invalid hex characters, which becomes 0 when used as a byte. Consider adding validation for invalid characters.
 export function hexToBytes(hex: string): Uint8Array {
   const clean = hex.replace(/^0x/i, "").replace(/\s/g, "");
   if (clean.length % 2 !== 0) {
     throw new Error("Invalid hex string length");
   }
+  if (!/^[0-9a-fA-F]*$/.test(clean)) {
+    throw new Error("Invalid hex characters");
+  }
   const bytes = new Uint8Array(clean.length / 2);
   for (let i = 0; i < clean.length; i += 2) {
     bytes[i / 2] = parseInt(clean.slice(i, i + 2), 16);
   }
   return bytes;
 }
37-56: Line 17 comment is misleading about supporting "proper partial reads"

The MockMemory class stores regions but only returns data if a read is fully contained within a single region. Reads spanning multiple preloaded regions silently return zeros. However, current host call handlers preload only the exact contiguous regions they need and don't perform spanning reads, so this isn't a practical issue. Consider clarifying the comment on line 17 to accurately describe the actual behavior and limitations.
src/store/workers/workersSlice.ts (1)
687-700: Consider error handling if resume execution fails.

After closing the dialog (lines 684-685), if runAllWorkers, stepAllWorkers, or refresh operations fail, the user loses the ability to retry from the dialog. Consider keeping the dialog open until execution succeeds, or providing a way to recover.

One approach is to wrap the resume logic in a try-catch and re-open the dialog on failure:
+    try {
       // Resume execution based on mode
       if (mode === "run") {
         dispatch(setIsRunMode(true));
         await dispatch(runAllWorkers()).unwrap();
       } else if (mode === "block") {
         const stepsToPerform = calculateStepsToExitBlockForAllWorkers(getState() as RootState);
         await dispatch(stepAllWorkers({ stepsToPerform })).unwrap();
       } else {
         // step
         await dispatch(stepAllWorkers({ stepsToPerform: 1 })).unwrap();
       }

       await dispatch(refreshPageAllWorkers());
       await dispatch(refreshMemoryRangeAllWorkers()).unwrap();
+    } catch (error) {
+      // Re-open dialog on failure so user can retry
+      dispatch(setHasHostCallOpen(true));
+      throw error;
+    }
src/store/debugger/debuggerSlice.ts (1)
86-93: Verify the hardcoded spiArgs default value.

The default spiArgs is set to new Uint8Array([0x18, 0x00, 0x00]). Consider adding a comment explaining what this value represents, or extracting it as a named constant in src/types/pvm.ts alongside DEFAULT_REGS and DEFAULT_GAS.
+// Default SPI arguments: 0x180000 (format TBD)
+export const DEFAULT_SPI_ARGS = new Uint8Array([0x18, 0x00, 0x00]);
Then import and use DEFAULT_SPI_ARGS in the initial state.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9897a5e and bc8828a.

⛔ Files ignored due to path filters (1)

package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (37)

package.json (1 hunks)
src/App.tsx (2 hunks)
src/components/DebuggerSettings/Content.tsx (1 hunks)
src/components/HostCallDialog/DefaultHostCallContent.tsx (1 hunks)
src/components/HostCallDialog/MemoryEditor.tsx (1 hunks)
src/components/HostCallDialog/handlers/FetchHostCall.tsx (1 hunks)
src/components/HostCallDialog/handlers/GasHostCall.tsx (1 hunks)
src/components/HostCallDialog/handlers/HostCallActionButtons.tsx (1 hunks)
src/components/HostCallDialog/handlers/InfoHostCall.tsx (1 hunks)
src/components/HostCallDialog/handlers/LogHostCall.tsx (1 hunks)
src/components/HostCallDialog/handlers/ProvideHostCall.tsx (1 hunks)
src/components/HostCallDialog/handlers/ReadHostCall.tsx (1 hunks)
src/components/HostCallDialog/handlers/TransferHostCall.tsx (1 hunks)
src/components/HostCallDialog/handlers/WriteHostCall.tsx (1 hunks)
src/components/HostCallDialog/handlers/YieldHostCall.tsx (1 hunks)
src/components/HostCallDialog/handlers/hostCallUtils.ts (1 hunks)
src/components/HostCallDialog/handlers/index.ts (1 hunks)
src/components/HostCallDialog/handlers/storageManager.ts (1 hunks)
src/components/HostCallDialog/handlers/types.ts (1 hunks)
src/components/HostCallDialog/index.tsx (1 hunks)
src/components/Instructions/BasicBlocks/CollapsibleInstructionsTable.tsx (2 hunks)
src/components/ProgramLoader/Examples.tsx (3 hunks)
src/components/ProgramLoader/Loader.tsx (1 hunks)
src/components/ProgramLoader/examplePrograms.ts (5 hunks)
src/components/ProgramLoader/loadingUtils.ts (3 hunks)
src/components/Registers/index.tsx (2 hunks)
src/hooks/useDebuggerActions.ts (3 hunks)
src/packages/web-worker/command-handlers/index.ts (1 hunks)
src/packages/web-worker/command-handlers/memory.ts (1 hunks)
src/packages/web-worker/command-handlers/set-memory.ts (1 hunks)
src/packages/web-worker/command-handlers/set-state.ts (1 hunks)
src/packages/web-worker/types.ts (3 hunks)
src/packages/web-worker/worker.ts (1 hunks)
src/pages/ProgramLoader.tsx (2 hunks)
src/store/debugger/debuggerSlice.ts (6 hunks)
src/store/workers/workersSlice.ts (3 hunks)
src/types/pvm.ts (1 hunks)

🧰 Additional context used

📓 Path-based instructions (8)

src/components/**/*.{ts,tsx}