Add incomplete-result signaling on parse failure (#67)#78
Open
bradjin8 wants to merge 7 commits into
Open
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
📝 WalkthroughWalkthroughAdds ParseWarningCollector and uses it in workspace listing/tabs/search to record skipped/failed parse events; services return (data, warnings) and APIs attach warnings to JSON. Replaces print/traceback error output with logging in export/pdf. Frontend normalizes responses and shows warning banners; tests cover behavior. ChangesStructured Logging & Parse-Warning Signaling
Sequence DiagramsequenceDiagram
participant Client
participant API as Workspaces API
participant Service as workspace_listing / workspace_tabs
participant KV as cursorDiskKV
participant Collector as ParseWarningCollector
Client->>API: GET /api/workspaces
API->>Service: list_workspace_projects(workspace_path)
Service->>KV: read composerData / bubble rows
KV-->>Service: rows (some invalid)
Service->>Collector: record_bubble_skipped()/record_composer_skipped()/record_composer_processing_failure()
Service-->>API: (projects, warnings)
API->>Collector: attach_to({"projects": projects})
API-->>Client: JSON { projects, warnings? }
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
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)
api/search.py (1)
160-177:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHandle non-string/NULL bubble payloads without aborting global search.
At Line 161,
json.loads(row["value"])can raiseTypeError(e.g., NULL KV value). That exception is not handled in this block and can terminate the global search pass via the outer catch, dropping valid results. Please treat this as a skipped bubble and keep processing.Proposed fix
- except (json.JSONDecodeError, ValueError): - parse_warnings.record_bubble_skipped() + except (json.JSONDecodeError, TypeError, ValueError) as e: + _logger.warning( + "Failed to decode bubble %s from cursorDiskKV: %s", + bid, + e, + ) + parse_warnings.record_bubble_skipped()🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@api/search.py` around lines 160 - 177, The code currently calls Bubble.from_dict(json.loads(row["value"]), ...) which can raise TypeError for non-string/NULL payloads and that exception is not handled; update the exception handling around Bubble.from_dict / json.loads (the try/except that populates bubble_map) to also catch TypeError and treat it like the other decode errors: call parse_warnings.record_bubble_skipped() and (optionally) emit a warning via _logger.warning similar to the SchemaError branch so the global search pass continues and valid bubbles are not dropped.templates/search.html (1)
73-85:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winClear previous parse-warning UI on new/failed searches.
Line 85 only executes on successful responses. If a later search fails, a prior warning banner can remain and misrepresent current results.
Proposed fix
async function performSearch(query, type) { const loading = document.getElementById('loading'); const countEl = document.getElementById('result-count'); const container = document.getElementById('results-container'); loading.style.display = 'flex'; countEl.style.display = 'none'; container.innerHTML = ''; + showIncompleteResultsBanner('parse-warnings-host', []); try { const res = await fetch(`/api/search?q=${encodeURIComponent(query)}&type=${type}`); const data = await res.json(); const results = data.results || []; showIncompleteResultsBanner('parse-warnings-host', data.warnings); @@ } catch (e) { loading.style.display = 'none'; + showIncompleteResultsBanner('parse-warnings-host', []); container.innerHTML = '<p class="text-danger">Search failed.</p>'; } }Also applies to: 112-115
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@templates/search.html` around lines 73 - 85, The prior parse-warning banner can persist across searches; update performSearch to clear the parse-warning UI at the start of a new search and in the error path: after container.innerHTML = '' call showIncompleteResultsBanner('parse-warnings-host', null) (or an empty array) to remove any existing banner, and in the catch block ensure you also call showIncompleteResultsBanner('parse-warnings-host', null) before returning/throwing; apply the same change to the other occurrence that currently only calls showIncompleteResultsBanner('parse-warnings-host', data.warnings') (lines around the second usage) so failed requests never leave stale warnings visible.
🧹 Nitpick comments (1)
tests/test_parse_warnings.py (1)
236-241: ⚡ Quick winAssert both parse-warning categories explicitly.
This assertion block can pass when only one parse-failure path is reported. Strengthen it to verify both conversation- and message-level warnings are present.
Proposed assertion tightening
self.assertIn("warnings", payload) types = {w["type"] for w in payload["warnings"]} self.assertEqual(types, {"parse_error"}) - counts = {w["count"] for w in payload["warnings"]} - self.assertIn(1, counts) - self.assertTrue(any(w["count"] >= 1 for w in payload["warnings"])) + details = {w["detail"] for w in payload["warnings"]} + self.assertTrue(any("conversation" in d for d in details)) + self.assertTrue(any("message" in d for d in details)) + self.assertGreaterEqual(sum(w["count"] for w in payload["warnings"]), 2)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/test_parse_warnings.py` around lines 236 - 241, The current assertions only check that parse_error warnings exist but can pass if only one warning scope is reported; update the test around payload and payload["warnings"] (variables types, counts, w) to explicitly assert both conversation- and message-level parse warnings are present by adding two assertions that there is at least one warning with the parse type and a scope indicator for conversation and at least one with the parse type and a scope indicator for message (e.g., assert any(w["type"] == "parse_error" and w.get("scope") == "conversation" for w in payload["warnings"]) and similarly for "message"), so the test fails unless both categories are reported.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@api/export_api.py`:
- Around line 218-225: The except block currently returns the raw exception
string to clients; change the response to a generic error message instead (e.g.,
{"error": "Export failed due to an internal error"}) while keeping the detailed
exception logged with _logger.error(..., exc_info=True); update the return
statement that uses jsonify to remove str(e) and return the generic message with
status 500 and ensure variable names (_logger, e, jsonify) and the same except
block around the export handler are used.
In `@api/pdf.py`:
- Around line 172-179: The exception handler in api/pdf.py currently returns the
raw exception text via jsonify(str(e)), exposing internals; retain the detailed
server-side logging using _logger.error(..., exc_info=True) but change the API
response to a generic error payload (e.g., jsonify({"error": "Failed to generate
PDF"}) , 500) so no raw exception message is returned; update the return in the
except block (around the _logger.error and jsonify calls) accordingly and ensure
exc_info remains true for logging.
In `@requirements-lock.txt`:
- Line 9: Update the PR to either document why the transitive dependency bump
click==8.4.1 (previously 8.4.0) is included with the parse-warning feature or
move the lockfile change into its own commit/PR; specifically, in the PR
description or changelog reference the requirements-lock.txt entry for click and
explain whether this bump was needed for a bugfix, compatibility, or tooling
change, and if it's unrelated to parse-warning, create a separate PR (or
separate commit) that only updates click in requirements-lock.txt to keep the
feature PR focused.
In `@static/js/app.js`:
- Around line 98-103: The returned normalized object may contain non-array
values for projects and warnings causing downstream failures; update the return
in static/js/app.js to coerce both fields to arrays (e.g., use
Array.isArray(body.projects) ? body.projects : [] and
Array.isArray(body.warnings) ? body.warnings : []) so projects.filter(...) and
similar operations are safe even if callers supply non-array values.
- Around line 118-124: In showIncompleteResultsBanner, the early return when
!warnings or !warnings.length skips removing a previously rendered banner;
always query for and remove any existing '.incomplete-results-banner' before
returning on clean responses. Locate the function showIncompleteResultsBanner
and the variables container, warnings, and existing, and move or add the removal
logic so existing.remove() is executed even when there are no warnings, then
return if there are no warnings.
In `@tests/test_parse_failure_logging.py`:
- Line 129: The unpacked return values from assemble_workspace_tabs are unused
and trigger lint warnings; rename them to prefixed-unused names (e.g., change
"payload, status = assemble_workspace_tabs(...)" to "_payload, _status =
assemble_workspace_tabs(...)" ) and apply the same change for the other
occurrence mentioned (line 159) so both unpacked variables are prefixed with an
underscore.
- Around line 64-66: The test writes a workspace.json with a hardcoded
"/tmp/proj" path; replace that literal with a path rooted in the temporary
workspace (use ws_dir) so the fixture is portable and passes static checks:
update the json.dump call to use a path built from ws_dir (e.g.,
os.path.join(ws_dir, "proj") or Path(ws_dir) / "proj") instead of "/tmp/proj"
and keep the sqlite3.connect to state.vscdb as-is; look for the workspace.json
write site and the surrounding ws_dir and state.vscdb references to modify.
---
Outside diff comments:
In `@api/search.py`:
- Around line 160-177: The code currently calls
Bubble.from_dict(json.loads(row["value"]), ...) which can raise TypeError for
non-string/NULL payloads and that exception is not handled; update the exception
handling around Bubble.from_dict / json.loads (the try/except that populates
bubble_map) to also catch TypeError and treat it like the other decode errors:
call parse_warnings.record_bubble_skipped() and (optionally) emit a warning via
_logger.warning similar to the SchemaError branch so the global search pass
continues and valid bubbles are not dropped.
In `@templates/search.html`:
- Around line 73-85: The prior parse-warning banner can persist across searches;
update performSearch to clear the parse-warning UI at the start of a new search
and in the error path: after container.innerHTML = '' call
showIncompleteResultsBanner('parse-warnings-host', null) (or an empty array) to
remove any existing banner, and in the catch block ensure you also call
showIncompleteResultsBanner('parse-warnings-host', null) before
returning/throwing; apply the same change to the other occurrence that currently
only calls showIncompleteResultsBanner('parse-warnings-host', data.warnings')
(lines around the second usage) so failed requests never leave stale warnings
visible.
---
Nitpick comments:
In `@tests/test_parse_warnings.py`:
- Around line 236-241: The current assertions only check that parse_error
warnings exist but can pass if only one warning scope is reported; update the
test around payload and payload["warnings"] (variables types, counts, w) to
explicitly assert both conversation- and message-level parse warnings are
present by adding two assertions that there is at least one warning with the
parse type and a scope indicator for conversation and at least one with the
parse type and a scope indicator for message (e.g., assert any(w["type"] ==
"parse_error" and w.get("scope") == "conversation" for w in payload["warnings"])
and similarly for "message"), so the test fails unless both categories are
reported.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: d39eab03-6b12-4d4e-8cc2-871cd5c79433
📒 Files selected for processing (31)
api/composers.pyapi/config_api.pyapi/export_api.pyapi/logs.pyapi/pdf.pyapi/search.pyapi/workspaces.pyapp.pymodels/__init__.pymodels/parse_warnings.pyrequirements-lock.txtscripts/export.pyservices/cli_tabs.pyservices/workspace_listing.pyservices/workspace_resolver.pyservices/workspace_tabs.pystatic/css/style.cssstatic/js/app.jstemplates/index.htmltemplates/search.htmltemplates/workspace.htmltests/test_invalid_workspace_aliases.pytests/test_models_wired_at_read_sites.pytests/test_parse_failure_logging.pytests/test_parse_warnings.pytests/test_project_layouts_dict_shape.pytests/test_workspace_listing_cli.pytests/test_workspace_listing_sql_errors.pytests/test_workspace_tabs_null_bubble.pyutils/cli_chat_reader.pyutils/path_helpers.py
bradjin8
force-pushed
the
feat/add-incomplete-result-signaling
branch
from
1561ea0 to
f7688d3
Compare
bradjin8
force-pushed
the
feat/add-incomplete-result-signaling
branch
from
f7688d3 to
bc79ce6
Compare
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
templates/search.html (1)
73-85:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winClear stale parse-warning banners on failed searches.
When a new search fails, the previous warning banner can remain visible because banner rendering/cleanup only runs on success. Clear it at request start (or in
catch) to avoid stale state.Proposed fix
async function performSearch(query, type) { const loading = document.getElementById('loading'); const countEl = document.getElementById('result-count'); const container = document.getElementById('results-container'); loading.style.display = 'flex'; countEl.style.display = 'none'; container.innerHTML = ''; + showIncompleteResultsBanner('parse-warnings-host', []); try { const res = await fetch(`/api/search?q=${encodeURIComponent(query)}&type=${type}`); const data = await res.json(); const results = data.results || []; showIncompleteResultsBanner('parse-warnings-host', data.warnings); @@ } catch (e) { loading.style.display = 'none'; + showIncompleteResultsBanner('parse-warnings-host', []); container.innerHTML = '<p class="text-danger">Search failed.</p>'; } }Also applies to: 112-115
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@templates/search.html` around lines 73 - 85, In performSearch, stale parse-warning banners can persist when a search fails; call the existing cleanup/render function to clear warnings at the start of the request (before fetch) and also in the catch block so any previous banner with id 'parse-warnings-host' is removed on error; update performSearch to invoke showIncompleteResultsBanner('parse-warnings-host', []) or the banner-clearing variant both immediately after setting up the UI and inside the catch handler (same for the related code around the other search branch at the 112-115 area) so warnings never persist after a failed request.api/search.py (1)
160-177:⚠️ Potential issue | 🟠 Major | ⚡ Quick winCatch
TypeErrorwhen decoding bubble JSON
json.loads(row["value"])in the bubble loop can raiseTypeErrorfor NULL/non-string DB values. The current handler only catchesjson.JSONDecodeErrorandValueError, so the exception can propagate to the outer global-searchexcept Exceptionand abort the whole global search pass. AddTypeErrorto the except tuple.Proposed fix
- except (json.JSONDecodeError, ValueError): + except (json.JSONDecodeError, TypeError, ValueError): parse_warnings.record_bubble_skipped()🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@api/search.py` around lines 160 - 177, The JSON decode of DB row values in the bubble loop can raise TypeError for NULL/non-string values, which isn't currently caught and can abort the search; update the exception handling around json.loads(row["value"]) in the block that constructs Bubble.from_dict to include TypeError in the except tuple (i.e., change the except (json.JSONDecodeError, ValueError): branch to except (json.JSONDecodeError, ValueError, TypeError):) so that parse_warnings.record_bubble_skipped() is called for these cases and schema drift logging via _logger.warning remains unchanged for SchemaError from Bubble.from_dict.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@api/search.py`:
- Around line 160-177: The JSON decode of DB row values in the bubble loop can
raise TypeError for NULL/non-string values, which isn't currently caught and can
abort the search; update the exception handling around json.loads(row["value"])
in the block that constructs Bubble.from_dict to include TypeError in the except
tuple (i.e., change the except (json.JSONDecodeError, ValueError): branch to
except (json.JSONDecodeError, ValueError, TypeError):) so that
parse_warnings.record_bubble_skipped() is called for these cases and schema
drift logging via _logger.warning remains unchanged for SchemaError from
Bubble.from_dict.
In `@templates/search.html`:
- Around line 73-85: In performSearch, stale parse-warning banners can persist
when a search fails; call the existing cleanup/render function to clear warnings
at the start of the request (before fetch) and also in the catch block so any
previous banner with id 'parse-warnings-host' is removed on error; update
performSearch to invoke showIncompleteResultsBanner('parse-warnings-host', [])
or the banner-clearing variant both immediately after setting up the UI and
inside the catch handler (same for the related code around the other search
branch at the 112-115 area) so warnings never persist after a failed request.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 11941e38-ea71-4437-b428-ff590b8d384e
📒 Files selected for processing (25)
api/composers.pyapi/config_api.pyapi/export_api.pyapi/pdf.pyapi/search.pyapi/workspaces.pyapp.pymodels/__init__.pymodels/parse_warnings.pyscripts/export.pyservices/cli_tabs.pyservices/workspace_listing.pyservices/workspace_tabs.pystatic/css/style.cssstatic/js/app.jstemplates/index.htmltemplates/search.htmltemplates/workspace.htmltests/test_models_wired_at_read_sites.pytests/test_parse_failure_logging.pytests/test_parse_warnings.pytests/test_project_layouts_dict_shape.pytests/test_workspace_listing_cli.pytests/test_workspace_listing_sql_errors.pyutils/cli_chat_reader.py
✅ Files skipped from review due to trivial changes (1)
- api/config_api.py
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
services/workspace_tabs.py (1)
583-590:⚠️ Potential issue | 🟠 Major | ⚡ Quick winDon't count generic composer-processing failures as parse errors.
Line 583 catches arbitrary downstream exceptions after the composer has already parsed successfully, but Line 589 still increments the
parse_errorwarning counter. That can turn resolver/rendering bugs into “incomplete results” warnings and silently downgrade real service defects into partial 200 responses.Suggested fix
except Exception as e: _logger.warning( "Failed to process Composer from composerData:%s: %s", composer_id, e, ) - parse_warnings.record_composer_skipped() + # Only JSON/schema failures should contribute to parse_error warnings. + continueIf you want to keep surfacing these as degraded results, this should use a separate warning type instead of
parse_error.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@services/workspace_tabs.py` around lines 583 - 590, The catch block in the composer processing code currently treats downstream exceptions as parse errors by calling parse_warnings.record_composer_skipped(); change this so downstream/runtime failures after successful parsing are NOT counted as parse_error: either remove the parse_warnings.record_composer_skipped() call and log the failure only, or replace it with a distinct warning API (e.g., parse_warnings.record_composer_processing_failure() or parse_warnings.record_degraded_result()) so that Composer parsing success/parse_error metrics remain accurate; update the catch in the composer processing function that logs "Failed to process Composer from composerData" to use the new/alternate warning instead.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@api/search.py`:
- Around line 175-177: The bubble-decode except block that currently catches
(json.JSONDecodeError, ValueError) around json.loads(row["value"]) must also
catch TypeError so NULL DB values don't escape and abort the global-storage
cursor; update that except to include TypeError and call
parse_warnings.record_bubble_skipped() as before. Also add a consistent
WARNING-level log message when a bubble decode is skipped (use the same logger
used elsewhere in api/search.py) that includes the row id/context and the
exception message. Apply the same pattern to the composer decode path: catch
(json.JSONDecodeError, ValueError, TypeError), call
parse_warnings.record_composer_skipped(), and emit a WARNING log with
identifying context and the exception details so both decode paths count and log
skips consistently.
In `@templates/index.html`:
- Around line 40-43: Before calling projRes.json() and passing the result into
normalizeWorkspacesResponse, check the HTTP status on projRes (e.g., projRes.ok
or projRes.status) and handle non-2xx responses by aborting the normal flow
instead of normalizing/rendering; on non-ok, read the error payload (text() or
json()) if needed and propagate or call the existing failure UI handler so
normalizeWorkspacesResponse, showIncompleteResultsBanner('parse-warnings-host',
...) and renderProjects(...) are not executed for error responses.
In `@templates/search.html`:
- Line 85: The incomplete-results banner is only updated on successful search
responses (showIncompleteResultsBanner('parse-warnings-host', data.warnings)),
so stale banners persist after errors; update the search error/failure handler
to clear the banner by calling
showIncompleteResultsBanner('parse-warnings-host', []) (or an explicit hide
function if available) whenever the request fails, ensuring the
parse-warnings-host banner is cleared in the catch/failure branch of the search
response flow.
---
Outside diff comments:
In `@services/workspace_tabs.py`:
- Around line 583-590: The catch block in the composer processing code currently
treats downstream exceptions as parse errors by calling
parse_warnings.record_composer_skipped(); change this so downstream/runtime
failures after successful parsing are NOT counted as parse_error: either remove
the parse_warnings.record_composer_skipped() call and log the failure only, or
replace it with a distinct warning API (e.g.,
parse_warnings.record_composer_processing_failure() or
parse_warnings.record_degraded_result()) so that Composer parsing
success/parse_error metrics remain accurate; update the catch in the composer
processing function that logs "Failed to process Composer from composerData" to
use the new/alternate warning instead.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 41e0c77f-62de-4acf-8afb-680ff47b7c7b
📒 Files selected for processing (18)
api/export_api.pyapi/pdf.pyapi/search.pyapi/workspaces.pymodels/__init__.pymodels/parse_warnings.pyservices/workspace_listing.pyservices/workspace_tabs.pystatic/css/style.cssstatic/js/app.jstemplates/index.htmltemplates/search.htmltemplates/workspace.htmltests/test_parse_failure_logging.pytests/test_parse_warnings.pytests/test_project_layouts_dict_shape.pytests/test_workspace_listing_cli.pytests/test_workspace_listing_sql_errors.py
✅ Files skipped from review due to trivial changes (1)
- tests/test_workspace_listing_cli.py
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When composer or bubble rows fail JSON/schema parsing, the app previously returned a shorter list with no indication that data was dropped. This change adds structured
warningsmetadata on the primary browse/search APIs and shows a banner in the web UI when results may be incomplete.ParseWarningCollectorinmodels/parse_warnings.pyto aggregate skipped composers and bubbles into API warnings (type: parse_error,count,detail).(projects, warnings)fromlist_workspace_projects; attachwarningsto tabs payloads inassemble_workspace_tabswhen any parse failures occurred.GET /api/workspaces,GET /api/workspaces/<id>/tabs, andGET /api/search(globalcursorDiskKVpath).GET /api/workspacesstill returns a JSON array when there are no warnings; when warnings exist, the response is{ projects: [...], warnings: [...] }.normalizeWorkspacesResponse(),showIncompleteResultsBanner(), and.alert-warningstyling on Projects, Workspace, and Search pages.Closes #67.
Test plan
pytest tests/test_parse_warnings.py— clean results (nowarnings), parse failures (warningspresent), service + API shapespytest tests/(315 passed locally)composerData:row in global storage → Projects page shows warning banner; workspace tabs/search show banner when applicableGET /api/workspacesreturns a plain arrayNotes
warningsbehave as before.load_bubble_map()skips in workspace listing into the collector so bubble-only failures on the project list also emitwarnings.Dependencies / lockfile
Base branch:
feat/replace-print-with-logging(stacked after #66 / #68).This PR does not change
requirements-lock.txt. Theclick==8.4.0→8.4.1pin (Flask transitive) lives in PR #76 as commitd55881f: Linux CIpip-compilenow resolvesclick==8.4.1within the Flask bound, and the lock freshness check failed while the file still pinned8.4.0. That is a routine lock refresh for CI, not required for parse-warning behavior. Dependabot also tracksclickseparately (dependabot/pip/click-8.4.1).Summary by CodeRabbit
New Features
Bug Fixes
UI/UX
Tests