Jira link on tests_create/tests_update fails with false "already connected" / duplicate-key error

[1illia1]

Summary

Linking multiple tests to the same Jira issue key via the API (tests_create / tests_update, v2 REST) fails intermittently, and a failed attempt leaves state behind that blocks later attempts — even on a test created with no Jira link at all.

Steps to reproduce

1. Create several tests in one suite, each with link: [{ action: "add", type: "jira", value: "PROJ-123" }].
2. Fire 6-8 of these calls back-to-back (mixed concurrent/sequential), all linking the same Jira key.

Observed behavior

• Concurrent/rapid creates: some fail with Mysql2::Error: Duplicate entry 'PROJ-123-Test-8564744' for key 'unique_jiraissues_for_test'. The numeric suffix increments across failures (8564744, 8564745, ..., 8564764), even for brand-new titles never created before — looks like an internal id/sequence collision, not a real duplicate link.
• Sequential retry of a failed create hits the same duplicate-key error on the next sequence number.
• Creating without link succeeds normally.
• Adding the link afterward via PATCH /tests/{id} on that same, freshly-created, link-free test fails with Validation failed: Jira Jira issue already connected for Test <id>. Retrying after several minutes gives the identical error.
• Two other creates in the same batch failed with Jira issue already connected for Test <id> for ids that don't correspond to any test we created — likely orphaned rows from the failed inserts above.

Impact

Can't reliably bulk-link tests to one Jira issue via the API. Workaround: omit link and keep the Jira key only in the test's free-text description — loses TQL (jira in [...]) and the Jira UI badge.

Suspected root cause

The jiraissues table's id generation isn't safe under back-to-back inserts for the same Jira key, and a failed insert doesn't roll back cleanly — it leaves a dangling row that later blocks unrelated tests from linking to that key.

Environment

• Testomat.io MCP server, tests_create/tests_update (v2 REST API)
• Observed 2026-07-31

[1illia1]

Additional detail: even on the 2 tests where the Jira link did succeed, the stored url for the jira_issue record was wrong. issues_list for those tests returned:

"url": "https://<instance>.atlassian.net/jira/software/c/projects/PROJ/boards/122/browse/PROJ-123"

instead of the plain issue URL:

https://<instance>.atlassian.net/browse/PROJ-123

So the linking mechanism isn't just racy on create (see above) — the URL it resolves to and caches also carries stray board context that doesn't belong in a direct issue link.

Workaround found: deleting the bad jira_issue record (DELETE /issues/{id} with type: jira_issue) and recreating the link via POST /issues with an explicit url field (instead of jira_id) stores the correct plain /browse/{key} URL. Trade-off: this creates a generic type: "issue" / source: "link" record instead of type: "jira_issue" / source: "jira", so it loses the native Jira badge/icon and won't match TQL's jira in [...] filter (only issue-type queries would find it, if those exist). But at least the link resolves to the right place.

[1illia1]

Found a more insidious version of this while fixing up the wrong-URL issue from my earlier comment: Testomat appears to auto-detect a Jira key inside the free-text description field and silently (re-)create the broken type: "jira_issue" link from that — no link param needed on the request at all.

Repro:

1. Create a test with a description that just happens to mention a ticket key in prose (no link param), e.g. ..._Source: PROJ-123 checklist item "..."_.
2. issues_list({ test_id }) shows a type: "jira_issue" / source: "jira" entry got created anyway, with the same broken board-scoped URL from my previous comment.
3. Delete that entry, then simply call tests_update({ test_id, description: "<same text, e.g. reformatted>" }) — a plain content edit, no link param, nothing jira-related in the request.
4. The broken jira_issue entry comes back. Every time the description (still containing the key) is updated, it's regenerated.

So this isn't just a create-time race under bulk linking (as in my first comment) — it's ongoing background behavior tied to whatever text-scanning triggers Testomat's Jira auto-link, and it fires on every update, not just once. Any workflow that stores a Jira key in a test's description (for traceability, changelog notes, etc.) without ever using the link param will still end up with this broken link appearing and needing to be manually deleted after every edit.

Workaround in use: after every create/update to a test whose description mentions a ticket key, list issues for that test and delete any type: "jira_issue" entry, keeping only a manually-added type: "issue" (plain url) link instead.

[1illia1]

Correction to my previous comment: I initially attributed the auto-recreated broken link to Testomat parsing the ticket key out of the test's description text. That was wrong — I just isolated it further.

Actual trigger: the test's parent suite has a jira link (added via suites_create/suites_update with link: [{ type: "jira", value: "PROJ-123" }]). Any test inside that suite gets the same broken type: "jira_issue" link auto-created on it too, with no link param on the test request at all — and it's recreated on every tests_create and every tests_update to that test, confirmed even when the update only changes wording and the test's own description never mentions the ticket key anywhere.

So the propagation is suite → test, not description-text → link. Same broken board-scoped URL as before, same workaround: after every create/update to a test in a jira-linked suite, issues_list({ test_id }) and delete the type: "jira_issue" entry, keeping only a manually-added type: "issue" (plain url) link.