fix(observability): tolerate bounded Sentry release visibility delay

[jaywedgeworth22]

Summary

The first reporter run after #1610 verified the live production SHA but received a missing-release response as Sentry was creating that same release. A reporter-only retry later recorded exactly one production deployment.

• Retry only confirmed HTTP 404 responses from the fixed existing-release GET, at most six reads with ten-second gaps.
• Distinguish a real 404 from a 200/null or malformed response. Authentication, network, validation and identity/project failures fail immediately.
• Do not retry writes, create another release, alter credentials, or trigger an application deployment. Existing release/environment deduplication stays unchanged.

Verification

29/29 focused Node tests passed. Independent review additionally exercised sixth-attempt success, deduplication, and non-retry behavior for network failures, malformed JSON, 403/429/500 and identity conflicts. Syntax/diff checks passed; hosted exact-head gates remain required.

Task state

Code/test-only follow-up; task notes remain here instead of effort-log uploads. This PR stays draft while the required named Codex review is quota-blocked and review permissions are pending. No auto-merge is requested. Existing #1610 technical rollout and Sentry receipt were verified, but its earlier automation merge did not satisfy the named-review gate.

Current-head handoff (2026-10-06 13:37 UTC)

Required hosted verify and gitleaks checks passed on dc72d1524dc2b2737aea1e258674061c43712424; all checks are terminal. 29 focused reporter tests and independent review passed, including confirmed-404-only release-read retry coverage. The PR remains draft with auto-merge disabled. Named Codex review is unavailable due the account quota; unresolved review feedback still requires triage/resolution. No merge, review bypass, or application deployment is authorized by this status note.

[kody-ai]

Code Review Completed! 🔥

The code review was successfully completed based on your current configurations.

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the @kody start-review command at the root of your PR.

• Validate Business Logic: Ask Kody to validate your code against business rules by adding a comment with the @kody -v business-logic command.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

​

[kody-ai]

🤔 Insufficient Task Context

I found a task linked to this PR, but it only contains minimal information (title only, no description or acceptance criteria). To perform a meaningful business rules validation, I need more details.

🔍 What I need to validate:

• Business requirements and acceptance criteria
• Expected behavior and business rules
• Edge cases and constraints to consider

💡 How to improve the task context:

• Add a description to the linked ticket
• Include acceptance criteria or business rules
• Describe the expected behavior after the change

⚠️ Important:

A task title alone is not sufficient to determine whether the implementation is correct or complete.

---

💡 This validation runs automatically only on the first review of a pull request. To run it again, comment @kody -v business-logic.

[kody-ai]

Unvalidated Sentry release payload in scripts/sentry-report-deploy.mjs: response.json() is an external-service trust boundary, but the manual checks leave existing unvalidated while indexing into it for version, ref, and projects. Define an explicit stripping Zod schema, reject safeParse failures, and perform the identity comparison only against the parsed data.

Kody rule violation: Validate every untrusted input with a zod schema at the trust boundary

const { z } = await import('zod');
const SentryReleaseSchema = z.object({
  version: z.string(),
  ref: z.string().nullable().optional(),
  projects: z.array(z.object({ slug: z.string() }).strip()).min(1),
}).strip();
const parsedExisting = SentryReleaseSchema.safeParse(existing);
if (!parsedExisting.success) {
  throw new Error('Sentry returned an invalid release payload');
}
const validatedExisting = parsedExisting.data;
if (
  validatedExisting.version !== version
  || (validatedExisting.ref && validatedExisting.ref !== version)
  || validatedExisting.projects.length !== 1
  || validatedExisting.projects[0].slug !== CONFIG.project
) {
  throw new Error('Existing Sentry release identity/project conflicts with the verified runtime');
}

Prompt for LLM

File scripts/sentry-report-deploy.mjs:

Line 140:

Unvalidated Sentry release payload in `scripts/sentry-report-deploy.mjs`: `response.json()` is an external-service trust boundary, but the manual checks leave `existing` unvalidated while indexing into it for `version`, `ref`, and `projects`. Define an explicit stripping Zod schema, reject `safeParse` failures, and perform the identity comparison only against the parsed data.

Suggested Code:

  const { z } = await import('zod');
  const SentryReleaseSchema = z.object({
    version: z.string(),
    ref: z.string().nullable().optional(),
    projects: z.array(z.object({ slug: z.string() }).strip()).min(1),
  }).strip();
  const parsedExisting = SentryReleaseSchema.safeParse(existing);
  if (!parsedExisting.success) {
    throw new Error('Sentry returned an invalid release payload');
  }
  const validatedExisting = parsedExisting.data;
  if (
    validatedExisting.version !== version
    || (validatedExisting.ref && validatedExisting.ref !== version)
    || validatedExisting.projects.length !== 1
    || validatedExisting.projects[0].slug !== CONFIG.project
  ) {
    throw new Error('Existing Sentry release identity/project conflicts with the verified runtime');
  }

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

​

​

[jaywedgeworth22]

Checked the applicable repository AGENTS.md and canonical AGENT-SYNC guidance: neither mandates Zod for this standalone, dependency-free Actions CLI. The workflow intentionally does not install application packages or execute their lifecycle scripts. The consumed release fields are validated before PUT: exact verified version, compatible ref, an actual projects array of length one, and exact project slug; malformed/null/conflicting responses fail closed. Unknown fields are never forwarded. Current tests cover malformed responses and identity conflicts. A blanket app-schema dependency recommendation is inapplicable here; the trust-boundary checks are explicit and remain required.