Search before asking
Use case
When DevLake collects Jira issues (jira:collectIssues), each page body is parsed with
json.Unmarshal. If a page that returned a successful (2xx) status has a body that
cannot be parsed as JSON — e.g. a truncated/partial response (connection dropped, or a
proxy buffered only part of the body), or in rare misconfigured-proxy cases an HTML body
served with a 200 status — the ResponseParser returns an error and the entire
collectIssues subtask fails, aborting the whole Jira collection.
Note: this is distinct from HTTP error statuses (e.g. 502/503/504), which are already
handled by the collector's retry logic. This request only concerns parse failures on
otherwise-successful responses.
On large Jira instances a single bad page (often on deep pagination with
expand=changelog) can kill an entire sync even though thousands of other pages are fine.
Description
A configurable flag JIRA_SKIP_UNPARSEABLE_ISSUES:
- default
false → current behaviour (surface the error, fail the subtask).
true → log a warning and skip the unparseable page, letting the rest of the
collection finish.
This keeps collection resilient on big/flaky Jira instances without hiding the problem
(the warning is still logged).
Related issues
No response
Are you willing to submit a PR?
Code of Conduct
Search before asking
Use case
When DevLake collects Jira issues (
jira:collectIssues), each page body is parsed withjson.Unmarshal. If a page that returned a successful (2xx) status has a body thatcannot be parsed as JSON — e.g. a truncated/partial response (connection dropped, or a
proxy buffered only part of the body), or in rare misconfigured-proxy cases an HTML body
served with a
200status — theResponseParserreturns an error and the entirecollectIssuessubtask fails, aborting the whole Jira collection.Note: this is distinct from HTTP error statuses (e.g.
502/503/504), which are alreadyhandled by the collector's retry logic. This request only concerns parse failures on
otherwise-successful responses.
On large Jira instances a single bad page (often on deep pagination with
expand=changelog) can kill an entire sync even though thousands of other pages are fine.Description
A configurable flag
JIRA_SKIP_UNPARSEABLE_ISSUES:false→ current behaviour (surface the error, fail the subtask).true→ log a warning and skip the unparseable page, letting the rest of thecollection finish.
This keeps collection resilient on big/flaky Jira instances without hiding the problem
(the warning is still logged).
Related issues
No response
Are you willing to submit a PR?
Code of Conduct