fix(report): raise FossologyApiError when report ID cannot be parsed#178
Open
Valyrian-Code wants to merge 2 commits into
Open
fix(report): raise FossologyApiError when report ID cannot be parsed#178Valyrian-Code wants to merge 2 commits into
Valyrian-Code wants to merge 2 commits into
Conversation
The regex used to extract the report ID from the API response message was `[0-9]*$`. With `*` (zero or more), the regex always matches even on a string with no trailing digits — `re.search` returns a match object whose group 0 is an empty string. The caller received `""` and no error, which then failed downstream as a confusing 404 or type error in `download_report`. Switch the quantifier to `+` (one or more) and raise `FossologyApiError` when no ID can be parsed, so the failure surfaces at the right point with a clear message. Adds a regression test that mocks a 201 response whose message has no trailing digits and asserts the new error path. Closes fossology#176 Signed-off-by: RAJVEER42 <irajveer.bishnoi2310@gmail.com>
There was a problem hiding this comment.
Pull request overview
This PR improves generate_report error handling by making report ID parsing fail clearly when the FOSSology API response message does not end with a numeric ID.
Changes:
- Requires at least one trailing digit when extracting the report ID.
- Raises
FossologyApiErrorwhen parsing fails. - Adds a regression test for an unparseable report-generation response message.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
fossology/report.py |
Updates report ID parsing and adds explicit parse-failure handling. |
tests/test_report.py |
Adds regression coverage for a 201 report response without a parseable report ID. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Author
|
Hi @deveaud-m , I’ve provided a minimal patch for this PR. Could you please review it when you have a chance? |
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
Closes #176.
In
fossology/report.py:56, the regex used to extract the report ID from the API response message was:[0-9]*(zero or more) always matches — even on a string with no trailing digits — sore.searchreturns a match object whose group 0 is an empty string"". The caller received that empty string with no error raised, and the failure surfaced later as a confusing404or type error insidedownload_report.Change
[0-9]+$(one or more)FossologyApiErrorif no ID can be parsed, with a descriptive message that includes the original response text# type: ignoresincematchis now narrowed to non-Nonebefore useCompatibility
Happy-path behaviour is identical: a message like
"Report will be generated in the back ground, report id is 42"still parses to"42". The only behaviour change is that callers now get a clear exception instead of a silent empty string when the message format is unexpected.Test plan
test_generate_report_unparseable_messagemocks a 201 response with no trailing digits and assertsFossologyApiErroris raisedpytest tests/test_report.py::test_generate_report_unparseable_messagepasses locallyruff checkcleanOpen questions for maintainers
:rtype: intbut the function returnsstr. I kept it asstrto minimise the diff. Happy to coerce tointand update the docstring in a follow-up if you'd prefer.FossologyApiErrorsince a real response is in hand. Let me know if a dedicated parsing exception would fit better.