fix(login): do not prompt for a default number without a TTY - #42
Merged
Conversation
The CLI pinned ^0.15.1, sixteen minor versions behind. That predates the webhook resource entirely, so `client.webhooks.unwrap()` — the SDK's Standard Webhooks verification helper — was not reachable from the CLI at all. This is the dependency bump only, no behaviour change. Verified: tsc --noEmit clean, build clean, 172 tests pass across 41 files, all 23 SDK call sites typecheck unchanged. Adopting Standard Webhooks in `webhooks listen --forward-to` follows separately so the version bump can be reviewed on its own.
`linq login --token <t>` is the documented non-interactive path, but on a paid account with more than one Linq Number it fell through to an interactive select() with no TTY guard. The prompt could never be answered, so the command blocked and exited before saveProfile() ran — no token was written, and every later command failed as unauthenticated with nothing explaining why. The token prompt earlier in the same command already guards on process.stdin.isTTY; the number picker did not. It now prompts only when stdin is a TTY, and otherwise defaults to the first number, saying which one it picked and pointing at `linq phonenumbers set`. Shared and sandbox accounts already auto-picked, so this only changes the paid multi-number path. This also clears the "Detected unsettled top-level await" warning on Node 26: bin/run.js awaits execute() at the top level, so a prompt that never resolves surfaces there rather than at the call site. The existing prompt test asserted behaviour that only holds with a terminal, so it now stubs isTTY explicitly, and a regression test covers the headless path.
Collaborator
Author
|
🎉 This PR is included in version 2.5.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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.
The problem
linq login --token <t>is the documented non-interactive path. On a paid account with more than one Linq Number it fell through to an interactiveselect()with no TTY guard:With no TTY the prompt can never be answered, so the command blocks and exits before
saveProfile(). No token is written, and every later command fails as unauthenticated with nothing explaining why. Reproduced from an agent shell: exits 0, writes nothing.It also explains the
Detected unsettled top-level awaitwarning on Node 26 —bin/run.jsawaitsexecute()at the top level, so a prompt that never resolves surfaces there rather than at the call site. Same root cause, not a separate Node compatibility issue.The change
Prompt only when
stdinis a TTY. Otherwise default to the first number, say which one was picked, and point atlinq phonenumbers set:Shared and sandbox accounts already auto-picked, so only the paid multi-number path changes.
Note for review
The existing test
paid user with multiple phones is promptedasserted behaviour that only holds with a terminal — it passed because the unguarded prompt ran regardless. It now stubsisTTYexplicitly, which makes its assumption visible, and a new regression test covers the headless path end to end (token persisted, no prompt, first number chosen).174 tests pass.