Skip to content

Replace except-pass with structured logging at parse sites #66

@bradjin8

Description

@bradjin8

Repository: cppa-cursor-browser
Assignee: Brad @bradjin8
Points: 3
Severity: High

Problem

Multiple from_dict call sites in the services layer use bare except Exception: pass to silently discard schema parse errors. The eval identifies services/workspace_listing.py as the primary offender, where failed composer parsing is caught and discarded with no log entry, no counter, and no signal to the operator. This is inconsistent with services/workspace_tabs.py, which logs the same class of error with context. The inconsistency is stamped across multiple call sites because the from_dict pattern is repeated manually across five model files. In a domain where the upstream Cursor schema is undocumented and changes without notice, silent data loss is the failure mode that most needs to be observable.

Acceptance Criteria

  • All except Exception: pass blocks at from_dict call sites are replaced with structured logging.warning() or logging.error() calls
  • Log messages include: the model class name, the raw input key/identifier, and the exception message
  • A module-level logger is configured in each affected service file using logging.getLogger(__name__)
  • No bare except: pass or except Exception: pass patterns remain in services/ files
  • At least 2 tests verify that parse failures produce log output (use caplog fixture in pytest)
  • Tests pass in CI
  • PR approved by at least 1 reviewer

Implementation Notes

The affected files are in services/workspace_listing.py (primary) and potentially services/workspace_db.py. Follow the pattern already established in services/workspace_tabs.py which does log errors — standardize on that approach. Use Python's logging module rather than print(). Set the log level to WARNING for recoverable parse failures (the session is skipped but others continue). Include the raw dict's identifying key (e.g., composer ID, workspace ID) so operators can investigate which records failed. Do not change the control flow — continuing past failed records is correct behavior.

References

  • Eval finding: Test 11 (Exception Safety) — part of the "Silent Failure Chain" compound
  • Related files: services/workspace_listing.py, services/workspace_tabs.py (reference pattern), services/workspace_db.py

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions