fix(jira): differentiate rejected token from a missing issue

[mbevc1]

Jira answers 404 both for an issue that does not exist and for one the
caller may not view, and a caller whose credentials Jira rejected may not
view any issue. GetJiraIssueInfo looked only at the status code, so an
expired Atlassian API token came back as IssueExists=false with no error
and was reported as a missing issue. A transport failure - DNS, proxy, TLS
or timeout - reached the same outcome through the response==nil case,
because the guard it fell through required a response to be present.

Classify the outcome in LookupStatus instead, with LookupReason carrying a
message for the caller to report. An error is still returned in exactly the
cases it was returned in before, so callers keep stopping where they used
to stop, and both new fields carry json:"-" so the attestation payload is
unchanged.

A 404 is only reclassified when the response carries positive evidence that
the credentials were rejected. That evidence is Seraph-era, so its absence
proves nothing and leaves the lookup classified exactly as it was.

The status code and those two headers are now logged at debug level, which
is what a run against an expired token needs to show whether the header is
present on Jira Cloud.

Also adjust GHA label filter.

Checklist

• Docs are autogenerated from CLI help — make sure the help text reflects your changes
• Helm chart (charts/k8s-reporter/) updated, if needed. Note: these changes live in a separate PR
• Terraform provider and related changes (terraform-provider-kosli, terraform-aws-evidence-reporter, terraform-aws-kosli-reporter) updated, if needed

[claude]

Claude finished @mbevc1's task in 4m 23s —— View job

---

Review — PR #1125

• Static analysis (go build, go vet, go mod tidy)
• Read the changed files
• Review for correctness, edge cases, tests
• Post review

---

Static analysis

Check	Result
go build ./...	clean
go vet ./...	clean (typechecks the test files too, so the new executeCommandC call site compiles)
go mod tidy + git diff --exit-code go.mod go.sum	clean

I could not run go test — the sandbox denied it, so I verified the exact-string assertions in internal/jira/jira_test.go by hand against go-jira@v1.17.0/error.go rather than by execution. Every one of the shapes I traced (JSON errorMessages, JSON errors map, empty non-JSON body, unparseable JSON body, HTML body, 2xx decode failure) produces exactly what the test pins. The Main workflow is still running; that's the authoritative check.

Assessment

The core of this is right, and the reasoning is unusually well documented. Three things stand out:

• The classification is conservative in the direction that matters. LookupUnverified is the zero value, so no path that never reached Jira can report an issue as found, and a 404 is reclassified only on positive evidence. 443a0c47 pins the absence case — a 404 with neither header stays IssueMissing — which is the regression that would have silently flipped every genuinely-missing issue on Jira Cloud.
• The blast radius is contained. json:"-" on both new fields keeps the payload byte-identical, and an error is returned in exactly the cases it was before, so --assert exit codes and compliance are unchanged. The change is purely in what the user is told.
• logger.Warn("%s", jiraUnconfirmedWarning(...)) — passing the reason as an argument rather than as the format string. LookupReason embeds a Jira response body, which can contain %; this is the right call and easy to get wrong.

Test quality is high: exact-string assertions where Contains had previously let leaks through, the nil-logger case, require.NotContains(t, errOut, "secret"), and TestGetJiraIssueInfoTransportReasonIsIssueIndependent — pinning the property the dedup depends on rather than the dedup's output — is the right level to test at.

Findings

Two inline comments, both low severity, neither blocking:

1. errorDetail ignores jiraErr.Errors — the fallback lets go-jira render the map, and go-jira returns from inside a range, so a multi-field error body reports one randomly chosen field and drops the rest. Same 403, different message each run.
2. credentialsRejected isn't consulted on the 2xx branch — an SSO login page reached through a followed redirect arrives as a 200 with HTML and reads as invalid character '<' looking for beginning of value, which is the same misdirection the 404 branch fixes.

Nit

internal/jira/jira.go:94-97 still returns nil, err when url.Parse fails — the only path that hands back a nil *JiraIssueInfo, and the only error that carries no explanation now that every other path sets LookupReason. TestGetJiraIssueInfo asserts require.NotNil(t, result) for every case it covers, so the suite already encodes "always returns a result" as the contract. Not reachable in practice (jira.NewClient parses the same URL), and the caller returns on the error either way.

One question, not a code issue

With a provably-rejected token the command now warns, but still reports the attestation with issue_exists: false for every issue and, under --assert, still exits non-zero. So a non-compliant attestation is permanently recorded against a trail on the basis of a lookup that is known to be meaningless — the warning is on stderr and won't be in the Kosli record. The PR describes preserving the error contract as deliberate, and that's a defensible line to hold in a fix. But a 401 aborts before reporting anything, and "Jira told us it rejected these credentials" is evidence of the same strength. Is treating the two differently intentional, or is erroring out on credentialsRejected a follow-up worth having?
· branch 20260821_jira_msgs

[claude]

errorDetail special-cases ErrorMessages but leaves the errors map to the text-trimming fallback, and go-jira renders that map by returning inside a range (error.go:56-60):

	if len(e.Errors) > 0 {
		for key, value := range e.Errors {
			return fmt.Sprintf("%s - %s: %v", key, value, e.HTTPError)
		}
	}

So for a body carrying more than one field error — {"errors":{"issuekey":"Issue does not exist","project":"No permission"}}, which is the documented shape — the message reports one randomly chosen field and silently drops the rest. Map iteration order is randomized per run, so the same 403 produces a different message each time; anything asserting on it (a golden file, a support ticket comparing two runs) sees a message that changes for no reason.

The struct is already in hand, so reading it directly is both complete and deterministic:

	if errors.As(err, &jiraErr) {
		if len(jiraErr.ErrorMessages) > 0 {
			return oneLine(strings.Join(jiraErr.ErrorMessages, "; "))
		}
		if len(jiraErr.Errors) > 0 {
			// go-jira renders this map by returning from inside a range, so it reports one
			// random entry; sorted keys report all of them, the same way every run
			fields := make([]string, 0, len(jiraErr.Errors))
			for key := range jiraErr.Errors {
				fields = append(fields, key)
			}
			sort.Strings(fields)
			for i, key := range fields {
				fields[i] = key + " - " + jiraErr.Errors[key]
			}
			return oneLine(strings.Join(fields, "; "))
		}
	}

sort is already imported. The existing "a 403 reporting a field error quotes it" case keeps its exact expectation (issuekey - Issue does not exist); worth a second case with two entries to pin the ordering.

Fix this →

[claude]

Enhancement, not a defect: credentialsRejected is consulted only on the 404 branch, but this branch is the other place where a rejected credential can arrive disguised as something else.

A Jira Server / Data Center instance behind SSO answers an unauthenticated API call with a 302 to a login page; http.Client follows it, so what lands here is a 200 with HTML, and the message becomes:

could not read Jira's answer for issue EX-1 at https://jira.example.com (status 200 OK): invalid character '<' looking for beginning of value

which reads as a Jira bug rather than "your PAT expired" — the same misdirection the 404 branch now fixes. The evidence is on the response already, and the header check is free:

	case response.StatusCode >= 200 && response.StatusCode <= 299:
		// a decode failure comes back alongside the 2xx it could not read, so Jira did answer
		message := fmt.Sprintf("could not read Jira's answer for issue %s at %s (status %s)",
			issueID, jc.BaseURL, response.Status)
		if reason, rejected := credentialsRejected(response.Header); rejected {
			// an SSO login page arrives as a 2xx the client followed a redirect to
			message += fmt.Sprintf("; Jira did not accept the %s (%s), so this may be a login page",
				jc.authDescription(), reason)
		}
		result.LookupReason = withDetail(message, errorDetail(err, response))

Same "presence is trustworthy, absence proves nothing" rule as the 404 branch, so it changes no outcome where the headers are absent — and it stays an abort either way.

Fix this →