Skip to content

fix(jtk): strip server-assigned fields and parse ruleUuid in auto create#109

Merged
rianjs merged 1 commit intomainfrom
fix/104-auto-create-bugs
Feb 8, 2026
Merged

fix(jtk): strip server-assigned fields and parse ruleUuid in auto create#109
rianjs merged 1 commit intomainfrom
fix/104-auto-create-bugs

Conversation

@rianjs
Copy link
Copy Markdown
Contributor

@rianjs rianjs commented Feb 8, 2026

Summary

  • Strip uuid, id, ruleKey, created, updated from exported rule JSON before POSTing to the Automation API, preventing "UUID already exists" rejection
  • Add ruleUuid to the create response parser so the success message shows the correct identifier

Closes #104

Test plan

  • Test: server-assigned fields are stripped from the request body
  • Test: response with only ruleUuid field shows correct UUID
  • Test: response with both uuid and ruleUuid prefers uuid
  • Existing tests (invalid JSON, file not found) still pass

Fixes two bugs in the automation create command:

1. Exported rule JSON containing uuid, id, ruleKey, created, and updated
   fields is now stripped before sending to the API, preventing "UUID
   already exists" errors during export-then-create workflows.

2. The response parser now handles the ruleUuid field returned by Jira
   Cloud, fixing the empty identifier in the success message.

Closes #104
@rianjs
Copy link
Copy Markdown
Contributor Author

rianjs commented Feb 8, 2026

TDD Assessment: PR #109

Summary

This PR fixes two bugs in automation create: (1) server-assigned fields (uuid, id, ruleKey, created, updated) are stripped before POSTing to the API, and (2) the ruleUuid field from Jira Cloud responses is now parsed for the success message. Both bugs are covered by well-structured tests. All 5 tests pass.

What's Covered

Bug 1 -- Field stripping (strips server-assigned fields):

  • Sends input JSON containing all 5 server-assigned fields, asserts each is nil in the received request body. Also asserts non-server fields (name, state) survive the round-trip. This directly exercises lines 61-71 on the happy path and confirms the core fix works.

Bug 2 -- ruleUuid parsing (response with ruleUuid field):

  • Server returns only ruleUuid (no uuid), test asserts the identifier appears in output. Exercises the new fallback at lines 100-102.

Identifier precedence (response prefers uuid over ruleUuid):

  • Server returns both uuid and ruleUuid, test asserts uuid wins and ruleUuid does not appear. Verifies the priority chain is correct.

Error paths (unchanged but still passing):

  • invalid JSON file -- covers the json.Valid check (line 55-57).
  • file not found -- covers the os.ReadFile error (line 51-53).

What's Not Covered (and Whether It Matters)

Uncovered path Lines Risk Matters?
json.Unmarshal into ruleMap fails 62-64 Dead code -- json.Valid already passed, so valid JSON will always unmarshal into map[string]interface{}. No. Unreachable in practice.
json.Marshal(ruleMap) fails 69-71 Practically unreachable -- marshaling a map[string]interface{} that was just successfully unmarshaled cannot fail under normal conditions. No.
opts.APIClient() returns error 74-76 Config/auth infrastructure error. Not related to this PR's changes. No -- this is pre-existing infra, not new logic.
client.CreateAutomationRule returns error 79-81 API call failure. A simple passthrough return err. No -- testing the HTTP client error path is the API package's responsibility.
Response unmarshal fails (malformed response) 93-97 Graceful degradation path: prints a generic success message. Low risk since it's a safe fallback. Minor gap. A test here would confirm the fallback message, but it's a defensive branch, not a behavior change.
Fallback to ruleKey identifier 103-105 Fallback when response has neither uuid nor ruleUuid but has ruleKey. Minor gap. Would be nice for completeness, but this is pre-existing logic that was not changed in this PR.
Fallback to id identifier 106-108 Last-resort fallback. Same as above. Minor gap. Pre-existing, unchanged.
Success message without name 112-114 Output branch when response has no name field. Minor gap. Cosmetic output path.

Verdict

Tests are well-written and sufficient for this PR. The two bugs are directly and thoroughly tested. The field-stripping test is particularly strong -- it checks both that unwanted fields are removed and that wanted fields survive, which guards against over-stripping regressions. The ruleUuid tests cover the new field and its priority relative to uuid.

The uncovered lines fall into two categories: (a) unreachable defensive branches that cannot be triggered without corrupting Go's JSON library, and (b) pre-existing fallback paths that were not changed in this PR. None of these represent meaningful risk for the changes being introduced.

Coverage of runCreate is 74.3%, with all gaps explained by the categories above.

@rianjs rianjs merged commit bf2b44d into main Feb 8, 2026
7 checks passed
@rianjs rianjs deleted the fix/104-auto-create-bugs branch February 8, 2026 12:06
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.

fix(jtk): auto create has two bugs — doesn't strip UUIDs and misparses response

1 participant