fix(data): raise clear error instead of crashing on missing invoice dates - #562
Open
Deez-Automations wants to merge 1 commit into
Open
Conversation
…ates (GenAI-Security-Project#290, GenAI-Security-Project#291) Invoice.to_dict() called .isoformat() directly on invoice_date and due_date with no null guard. Both columns are NOT NULL in the schema, so this only surfaces via corrupted/anomalous data -- but when it does, it crashed with an opaque AttributeError instead of a diagnosable error, and the crash propagated straight into payment processing via get_invoice_for_payment. Now raises a clear ValueError naming the invoice and the missing field. Verified no code anywhere catches AttributeError around a to_dict() call, so nothing depends on the old crash behavior. Fixes GenAI-Security-Project#290 Fixes GenAI-Security-Project#291
There was a problem hiding this comment.
Pull request overview
This PR hardens invoice serialization in the data layer by turning a previously opaque AttributeError (from calling .isoformat() on missing dates) into a clear, diagnosable ValueError, preventing confusing crashes in payment processing paths that rely on Invoice.to_dict().
Changes:
- Add explicit
Noneguards forinvoice_dateanddue_dateinInvoice.to_dict()that raiseValueErrorwith invoice ID + missing field name. - Add unit tests covering both missing-date cases and a regression case where both dates are present.
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
finbot/core/data/models.py |
Adds explicit validation for missing invoice date fields before serializing to dict. |
tests/unit/data/test_invoice_model.py |
Introduces targeted unit coverage for the new ValueError behavior and a regression test for valid dates. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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
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
Fixes #290, fixes #291.
Invoice.to_dict()calls.isoformat()directly oninvoice_dateanddue_datewith no null guard. Both columns areNOT NULLin the schema, so this is only reachable via corrupted or anomalous data (e.g. a raw SQL write bypassing the ORM constraint) — but when it happens, it crashed with an opaqueAttributeError: 'NoneType' object has no attribute 'isoformat'instead of a diagnosable error. Sinceget_invoice_for_payment(finbot/tools/data/payment.py) callsto_dict()directly, the crash propagated straight into payment processing with no useful message.Fix
Raises a clear
ValueErrornaming the invoice ID and the specific missing field, instead of crashing with an unhandledAttributeError. Checked that no code anywhere in the codebase catchesAttributeErroraround ato_dict()call, so nothing depends on the old crash type/behavior.Test plan
tests/unit/data/test_invoice_model.py— reproduces both crashes first (confirmed failing against the unfixed code, exactAttributeErrormatching both issue reports), then confirms the fixpytest tests/unit/data/test_invoice_model.py— 3/3 passing