# AUTO_RANDOM Generated-value Boundary

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "auto-random-generated-value-boundary-2026-08-14",
  "problems": [
    {
      "problemId": "auto-random-explicit-value-range-boundary",
      "summary": "An AUTO_RANDOM compatibility answer correctly bounded implicitly generated IDs but did not state that existing or explicitly inserted IDs can remain outside the configured R range and must be checked separately for the customer's downstream MaxInt64 requirement.",
      "status": "optimized_verified",
      "applicability": "Direct feature or capability answers where the customer relies on AUTO_RANDOM(S, R) to keep every downstream ID within a numeric compatibility limit.",
      "issueKeys": ["NAID-12162"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/NAID-12162#problem:auto-random-explicit-value-range-boundary"
      ],
      "signalTextIncludesAny": [
        "auto_random range only applies to automatically generated ids",
        "explicitly inserted ids may exceed maxint64",
        "existing ids are not constrained by r"
      ],
      "observedThrough": "2026-08-14",
      "effectiveAt": "2026-08-14T09:14:26Z",
      "verifiedAt": "2026-08-14T09:24:53.793Z",
      "attemptedAction": "Require AUTO_RANDOM numeric-compatibility answers to distinguish the R-bounded automatic generation path from existing, migrated, and explicit values, and to keep that load-bearing caveat in the customer reply.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/NAID-12162?focusedCommentId=23416701"
    }
  ]
}
-->

- Optimization ID: `auto-random-generated-value-boundary-2026-08-14`
- Owner: auto-oncall product knowledge consumed by Primary Analysis and the
  Scenario Router
- Source reference: `NAID-12162`, internal Auto-oncall comment `23416701`, and
  subsequent human reply `23417138`
- Implementation status: deployed to staging in image `8e5847bd85933d4fc5aae445e1236364d3a18763`
- Effective status: `optimized_verified`

## Bounded problem

The Auto-oncall answer correctly stated that `AUTO_RANDOM(5, 63)` keeps
implicitly generated unsigned IDs within `[0, 2^63-1]`. It also warned against
explicit inserts because of allocation and collision risk. It did not connect
the explicit-value path to the customer's actual compatibility goal: the
configured `R` range does not cap migrated, existing, or explicitly supplied
values, so those values can still exceed `MaxInt64` and require a separate
check.

This is a direct-answer completeness issue. The existing
`feature_usage_or_capability / direct_answer / provider=none` routing is
correct, and the versioned official documentation was available to the run.

## Candidate change

- Keep the documented automatic-generation conclusion.
- State that `R` does not cap existing, migrated, or explicit values.
- When the customer's goal covers every downstream ID, require a separate
  check of those values and explicit-insert paths.
- Do not replace that scope boundary with a generic collision warning.

## Verification status

- Service PR `tidbcloud/aisupport#917` and app-delivery PR
  `tidbcloud/app-delivery#77304` deployed image
  `8e5847bd85933d4fc5aae445e1236364d3a18763`; the staging Pod became Ready at
  `2026-08-14T09:14:26Z` with zero restarts and both health endpoints passing.
- Historical read replay `51d1d8c0-76cd-46d6-a302-be622d5f6b84` preserved
  `[0, 2^63-1]` for implicitly generated unsigned values and explicitly stated
  that migrated, existing, and explicitly inserted values require a separate
  `MaxInt64` check. The bounded criterion passed; its Judge verdict was
  `equivalent`.
- Write replay `e11aa035-960a-4839-9d5f-3a2827847e1d` persisted DB run
  `150042` and updated the existing Jira internal comment `23416701` in place.
  Jira readback found exactly one Auto-oncall comment, `public=false`, with the
  expected paired body and explicit/migrated-value boundary.

## Unresolved gaps

- This verification covers the generated-versus-explicit value scope boundary,
  not every implementation-level claim for every TiDB version. The write replay
  Judge preferred the human answer's target-version implementation evidence;
  that does not reproduce this bounded omission.

## Next validation action

Treat a later answer that again implies `R` constrains existing, migrated, or
explicit values as a new regression signal; do not suppress unrelated
AUTO_RANDOM answer-quality gaps.