Skip to content

fix(open): stop telling callers to accept an unrecognized iOS alert - #3935

Merged
thymikee merged 1 commit into
callstack:mainfrom
airowe:fix/open-alert-unrecognized-guidance
Oct 24, 2026
Merged

thymikee merged 1 commit into
callstack:mainfrom
airowe:fix/open-alert-unrecognized-guidance

Conversation

@airowe

@airowe airowe commented Oct 24, 2026 •

Copy link
Copy Markdown
Contributor

Summary

For launchConfirmationReason: "alert-unrecognized", open cannot tell a translated Open in prompt from the app's own alert. The warning still said to answer with alert accept. When the alert was the App Tracking Transparency prompt, that granted tracking. The warning, help open, and commands.md now say to read the alert with alert get and accept it only when it is the launch confirmation. url-owner-unresolved keeps its alert accept guidance.

Returning the alert's title and buttons in the open result (option 2 in the issue) is not included; the triage comment left it as a separate maintainer decision.

4 files: the warning, its existing test's pattern, the open help text, and commands.md.

Closes #3921

Validation

  • Tested SHA 876bebf66 (base c48d27a81).
  • pnpm check:affected --run --head 876bebf66: passed, exactCommit=true. format, lint, typecheck, layering, fallow, build, vitest-related, command-docs, docs-links and docs-prose passed; replay/device lanes skipped.
  • The updated warning test fails on base and passes at head.
  • Wording-only change to a warning and help text; no dispatch or device behavior changes, so no device run.

🤖 Generated with Claude Code

View guided diff

An alert-unrecognized launch confirmation can be the app's own alert, such
as the App Tracking Transparency prompt, and following the warning's
`alert accept` granted it. The warning, `help open`, and commands.md now
say to read the alert with `alert get` and accept only a launch
confirmation.

Closes callstack#3921

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@thymikee

Copy link
Copy Markdown
Member

I found no code problems in 876bebf. The change only touches a warning string, help text and docs, so it looks good to merge on the code side. The Smoke Tests gate is red on the iOS phase (macOS passed), and I did not see a cause in the diff. I did not run the unit test or check:affected locally, and I did not check whether any smoke script asserts on the old warning text. Please rerun the iOS smoke job, or confirm it also fails on main, before merging.

@thymikee thymikee added the ready-for-human Valid work that needs human implementation, judgment, or maintainer merge label Oct 24, 2026
@airowe

airowe commented Oct 24, 2026

Copy link
Copy Markdown
Contributor Author

Checked the iOS smoke failure at 876bebf66:

  • No test checks the old wording. No script or test under test/, scripts/, .github/ or apple/ asserts on the old warning text. The only check on that text is the updated unit test, which passes in check:affected --run --head 876bebf66 (exactCommit=true).
  • The job stopped before any test ran. The iOS phase built the runner (TEST BUILD SUCCEEDED), then failed with The Apple runner budget ran out before this step began (packages/platform-apple/src/runner/runner-phase-budget.ts).
  • The same lane passes elsewhere. It passed on fix(selectors): refuse a zero-area press target instead of tapping its origin #3934 (same base) and on main at c48d27a81.

I can't rerun jobs from a fork. Could you rerun the iOS smoke job?

🤖 Addressed by Claude Code

@thymikee
thymikee merged commit ed798f9 into callstack:main Oct 24, 2026
14 of 15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready-for-human Valid work that needs human implementation, judgment, or maintainer merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

iOS: the alert-unrecognized warning of open --launch-url says to alert accept, which grants App Tracking Transparency when that is the alert

2 participants