add issue uuid to webhook call to api-server

[j1philli]

needed for https://github.com/beeper/beeper-services/pull/448

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• New Features
  • Submission responses now include the Issue ID for created issues.
  • Webhook payloads now include the Issue ID.
  • Issue ID is consistently propagated across submission and webhook flows, improving traceability in integrations.
  • No changes required to existing configurations; the new field is optional where applicable.
  • This update provides clearer linkage between created issues and downstream notifications without altering existing behavior.

Walkthrough

Adds IssueID to response and webhook payload. In submitLinearIssue, sets submitResponse.IssueID from Linear issue creation result. In submitWebhook, includes this IssueID in webhookRequest. Structures submitResponse and webhookRequest updated to carry the new field.

Changes

Cohort / File(s)	Summary
Submission response and webhook propagation submit.go	- Add IssueID to submitResponse (json:"issue_id,omitempty") and webhookRequest (json:"issue_id") - Set resp.IssueID = createResp.IssueCreate.Issue.ID in submitLinearIssue - Pass SubmitResponse.IssueID into webhookRequest.IssueID in submitWebhook

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant Client
  participant Service as Service (submit.go)
  participant Linear as Linear API
  participant Webhook as Webhook Receiver

  Client->>Service: Submit request
  Service->>Linear: Create Issue
  Linear-->>Service: createResp (Issue.ID)
  note right of Service: New: resp.IssueID = Issue.ID
  Service->>Webhook: webhookRequest{ ..., issue_id: resp.IssueID }
  Webhook-->>Service: 2xx/ack
  Service-->>Client: submitResponse{ ..., issue_id }

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title clearly summarizes the main change by specifying that the issue UUID is being added to the webhook call to the API server, matching the changeset focus on propagating the new IssueID field.
Description Check	✅ Passed	Although minimal, the description directly relates the change to its dependency on the referenced beeper-services pull request and is on-topic with the changeset.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch j1philli/linearCustomerRequests

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

• Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
• Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

submit.go (1)

842-848: Propagation to webhook payload: LGTM; consider a small regression test

Mapping submitResp.IssueID into the webhook request looks correct. Consider adding a unit/handler test that asserts the encoded JSON includes "issue_id":"<uuid>" on successful Linear creates to prevent regressions.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 73e4eae and 9ab9136.

📒 Files selected for processing (1)

• submit.go (4 hunks)

🔇 Additional comments (3)

submit.go (3)

123-127: Add IssueID to submitResponse: LGTM

Optionality via omitempty is appropriate and keeps the wire shape stable when Linear is disabled.

---

828-834: Validate empty IssueID handling in submitWebhook
The webhookRequest struct always includes "issue_id" (even when empty) since it lacks omitempty. Confirm that submitWebhook (and any downstream logic) tolerates an empty IssueID—for example, it doesn’t attempt to parse it as a UUID or error when it’s "". If it doesn’t, either add omitempty to the JSON tag or only set IssueID when Linear integration is enabled and document the empty-string case.

---

808-811: MutationCreateIssue includes id, IssueID will be populated
Verified that the GraphQL mutation selects id and the Go response type defines Issue.ID, so resp.IssueID is correctly set.