feat(preprod): Prefer build_number_raw for display#119267
Merged
Merged
Conversation
The backend now stores the raw, unparsed build identifier alongside build_number, since build_number can be a large synthesized int for Apple builds with a dotted CFBundleVersion (#119262). Add the field to BuildDetailsAppInfo and prefer it over build_number at every site that renders a build number to a user: the install header, build details header/title, builds table, build comparison item and selected-builds panel, and the base-build VCS info link. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
github-actions
Bot
added
the
Scope: Frontend
…ld-number-raw-frontend
The build_number_raw ?? build_number fallback was duplicated across 7 call sites. Extract it into getBuildNumber(), colocated with BuildDetailsAppInfo alongside the file's existing helpers (isSizeInfoCompleted, getMainArtifactSizeMetric, etc.), so a future call site can't forget the fallback and the precedence logic has one place to change. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mtopo27
approved these changes
Jul 9, 2026
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
The backend schema for build_number_raw has no minLength, so an empty string passes validation. getBuildNumber used ?? to fall back to build_number, which only triggers on null/undefined, not empty string — so an empty build_number_raw would win and render as literal empty parentheses. Switch to || in getBuildNumber, which correctly falls through on empty string. Also fixes the buildNumber !== null render guard in preprodBuildsTableCommon.tsx, which had the same gap (and additionally mishandled undefined, though that case is currently masked since the API always serializes these fields as null rather than omitting them). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
build_number_raw) alongsidebuild_number, sincebuild_numbercan be a large synthesized int for Apple builds with a dottedCFBundleVersion(feat(preprod): Store raw build number for display purposes #119262). Left unhandled, that synthesized int would render directly to users.build_number_rawtoBuildDetailsAppInfoand prefers it (build_number_raw ?? build_number) at every site that renders a build number: install header, build details header/title, builds table, build comparison item, selected-builds panel, and the base-build VCS info link.build_number_rawis alwaysnulland this is a no-op, falling back tobuild_numberexactly as before.Test plan
preprodBuildsTable.spec.tsxandbuildDetails.spec.tsxasserting the raw value is preferred over a synthesized intpnpm typecheckandpnpm lint:jspassing