[gorlix]

What

The task-ref parser matched the tail of dashed tokens: TRIM-UI-200 yielded UI-200, which could link a change request to no task, or to a project whose prefix is UI.

How

• New findTaskRefs helper built on FindAllStringSubmatchIndex (RE2 has no lookbehind), used by saveChangeRequest instead of taskRefRE.FindAllStringSubmatch.
• A match directly preceded by - is dropped only when the segment before that dash is an all-uppercase token ([A-Z][A-Z0-9]*, at the start of the text or after a non-alphanumeric). So TRIM-UI-200 is ignored (not reinterpreted as TRIM-200, since PROJ-N stays the only task identifier), while fix-PACA-12-login and feature-PACA-12 keep linking.

Trade-off

This is a heuristic on case. An uppercase prefix followed by - and another key (e.g. HOTFIX-PACA-12) is always ignored. Dropping every match preceded by a dash would also have stopped fix-PACA-12-login from linking, which works today.

Tests

Table-driven TestFindTaskRefs: feat/PACA-12-login, paca/PACA-1, Fix PACA-12, fix-PACA-12-login and feat-paca-12 match; TRIM-UI-200 yields nothing; fix TRIM-UI-200 and PACA-7 yields only PACA-7.
go vet ./... and go test ./... in services/api pass (no Postgres needed).

Manual test: a merge request on a real GitLab CE with branch fix-TST-2-search was linked to task TST-2 through the webhook; one with branch TRIM-UI-3 was linked to nothing. That project had only the TST prefix, so the second case does not tell the old parser apart from the new one: the unit tests do.

Refs #649

🤖 Generated with Claude Code

[pullfrog]

✅ No new issues found.

Reviewed changes — reviewed the single commit f422fe2 (2 files, +76/−3): a targeted fix to how Git task refs are parsed out of a change request's branch and title, verified by reading the full diff, the surrounding saveChangeRequest/trackChangeRequest flow, the gitdom.Store.FindTaskByRef contract, and running a standalone repro plus go test/go vet on internal/service/git.

• findTaskRefs parser (services/api/internal/service/git/service.go): new helper built on FindAllStringSubmatchIndex that drops a PREFIX-N match only when it is directly preceded by - and the run before that dash is an all-uppercase token, so TRIM-UI-200 no longer resolves as UI-200. Group indexing (m[2]:m[3] prefix, m[4]:m[5] number) and the surrounding seen dedup are correct, and the change only removes matches, so it cannot introduce new mis-links.
• saveChangeRequest wiring: now consumes findTaskRefs; the FindTaskByRef call and linking loop are otherwise unchanged.
• TestFindTaskRefs: table-driven coverage for kept refs (fix-PACA-12-login, feat-paca-12, Fix PACA-12) and dropped tails (TRIM-UI-200, mixed with PACA-7).

I independently reproduced the parser on the exact issue-649 cases: feat/TRIM-UI-200-x, TRIM-UI-200, and HOTFIX-PACA-12 all yield nothing, while TRIM-200 and fix-PACA-12-login still link. The documented trade-off (an uppercase prefix followed by a dash and another key is ignored) is real and intentional, and generated branch names use a lowercase type/PREFIX-N form, so they are unaffected.

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}