Skip to content

Fix production hang and nil-priority crash in epic sync - #23

Merged
ImTheKai merged 2 commits into
Percona-Lab:mainfrom
ImTheKai:fix/board-hang-and-nil-priority
Aug 12, 2026
Merged

Fix production hang and nil-priority crash in epic sync#23
ImTheKai merged 2 commits into
Percona-Lab:mainfrom
ImTheKai:fix/board-hang-and-nil-priority

Conversation

@ImTheKai

@ImTheKai ImTheKai commented Aug 12, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Two bugs found:
  • upsert_epic in app/services/jira_sync.rb set priority with no fallback for nil. epics.priority is NOT NULL default 0, so any epic that loses its Jira priority field crashes JiraSyncJob on every sync tick. discover_closed_epics! already had the || 0 fallback; this brings the main per-tick path in line with it.
  • jira_wiki_to_html in app/models/issue.rb used line.strip.empty? to detect blank lines, but plain Ruby strip doesn't remove U+00A0 (non-breaking space). A real Jira ticket description (PG-2635) had a line containing only a non-breaking space, which fell through to the paragraph-continuation loop — that loop uses Rails' .present?, which does treat it as blank, so it consumed zero lines and never advanced. The result was an infinite loop pinning the Puma request thread at ~100% CPU forever, with no exception and no process crash, which is why the outage was hard to detect (Solid Queue background jobs, running in separate forked processes, kept working fine the whole time).

upsert_epic (the per-sync path run on every JiraSyncJob tick) set
priority to priority_int(...) with no fallback. epics.priority is
NOT NULL default 0, so an epic that loses its Jira priority field
would raise on every sync tick, matching the fallback already used
in discover_closed_epics!.

Signed-off-by: Kai Wagner <kai.wagner@percona.com>
jira_wiki_to_html's blank-line check used line.strip.empty?, which
does not strip U+00A0. A line containing only a non-breaking space
(seen in a real Jira ticket description) fell through to the
paragraph branch, whose continuation loop uses Rails' .present? and
correctly treats it as blank -- so the loop consumed zero lines and
never advanced, spinning the request thread at ~100% CPU forever.

Switched to line.blank? so both checks agree on what counts as
blank.

Signed-off-by: Kai Wagner <kai.wagner@percona.com>
@ImTheKai
ImTheKai merged commit 63d2e24 into Percona-Lab:main Aug 12, 2026
7 of 8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants