mirror of https://github.com/run-llama/llama-ui.git synced 2026-08-25 09:19:49 -04:00

Files

T

Adrian Lyjak 2a47997002 fix debugger boolean bug (#230 )

* fix: correct boolean value display in workflow debugger schema editor

The boolean field in JsonSchemaEditor was incorrectly displaying "True"
for string "false" values because Boolean("false") evaluates to true
(any non-empty string is truthy in JavaScript).

Changed from String(Boolean(values[fieldName])) to explicit comparison
that properly handles both boolean and string representations of
true/false values.

Added regression test to verify boolean fields display correctly for
both boolean primitives and string representations.

* fix: initialize boolean fields to false to prevent missing field errors

When a boolean field in the schema editor had no value set (undefined),
it would not be included in the form data payload. This caused Pydantic
validation errors for required boolean fields without defaults.

Now boolean fields are automatically initialized to false when they are
undefined, ensuring they are always included in the payload sent to the
workflow.

* fix: only initialize required boolean fields, use null for nullable

Refined boolean field initialization logic:
- Only initialize boolean fields that are in the required array
- For nullable boolean fields, initialize to null instead of false
- Optional boolean fields are left undefined (not included in payload)

This allows optional boolean fields to remain unset while still
preventing Pydantic validation errors for required boolean fields.

* feat: add nullable boolean support with None option in debugger

- Add nullable widget for boolean fields that shows True/False/None options
- Display null values correctly as "None" in the dropdown
- Only initialize required boolean fields (optional fields remain undefined)
- Use null for nullable fields, false for non-nullable required fields
- Add comprehensive tests for nullable boolean handling
- Add changeset for patch release

* wop

* test: add failing tests for handler 500 response bug

When the workflow server returns HTTP 500 with valid handler data
in the body (e.g., status: "failed"), the sync() function ignores
the response.error field and resets state to "not_started".

These tests document the expected behavior and will pass once
the bug is fixed.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix: handle 500 responses with valid handler data in sync()

The workflow server returns HTTP 500 for failed handlers but includes
valid handler data in the response body. The hey-api client puts this
in response.error instead of response.data.

The fix checks if response.error contains valid handler data (has
handler_id and status fields) and uses it to update state. Otherwise,
it treats it as a real API error and sets loadingError.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* test server changes

* test: add failing tests for anyOf nullable type patterns

Pydantic generates anyOf schemas for nullable types like `bool | None`:
  "anyOf": [{"type": "boolean"}, {"type": "null"}]

The current code doesn't recognize this pattern and falls back to
a JSON textarea instead of the proper type-specific input.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix: handle anyOf nullable type patterns from Pydantic

Pydantic generates anyOf schemas for nullable types like `bool | None`:
  {"anyOf": [{"type": "boolean"}, {"type": "null"}], "default": null}

Added normalizeSchemaProperty() to extract the actual type and nullable
flag from anyOf patterns. This ensures nullable boolean, integer, and
string fields render with proper type-specific inputs instead of falling
back to the JSON textarea.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* bump lock

* adjust changeset comments

---------

Co-authored-by: Claude <noreply@anthropic.com>