Conversation
…old them to wait Four defects on one login screen, reported by Dmitrii <dsbusiness2026@gmail.com>. sentCodeTypeApp delivers to other logged-in sessions of the same number. A user whose only session is the one they are creating has nowhere to receive it. The bridge discarded auth.sentCode's Type, Timeout and NextType and let the UI guess "app/SMS", so that user was advised to watch for an SMS that could never arrive. SendCode now returns all four and the handler states the channel Telegram named. "Request a new code" called sendCode again, which is free to pick the same dead channel. It now calls auth.resendCode, honours Telegram's own timeout instead of a locally invented one, and refuses outright when Telegram nominated no next channel rather than pretending to try. QR login is added as the route that does not depend on code delivery at all: auth.exportLoginToken, polled, with SESSION_PASSWORD_NEEDED handed to the existing Check2FA so 2FA reuses the screen that already exists. The in-flight login lived in process memory and in a FileStorage on a container filesystem, so any redeploy between "enter phone" and "enter code" silently killed it. It now persists to Postgres and getClient restores it. The storage this uses was already written and unused, aimed at a telegram_sessions table nothing in the repository created; the table is created here too. Tests cover the delivery-type mapping, that an unknown type is never reported as "app", and that a resend without a next channel refuses.
This branch has not been deployed
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.
Four defects on one login screen, reported by Дмитрий dsbusiness2026@gmail.com against app.t27.ai.
The report, and what was true
sentCodeTypeAppdelivers the login code to other logged-in sessions of the same number. A user whose only session is the one they are trying to create has nowhere to receive it — the code is not lost in transit, it was delivered to a set of zero devices. The bridge discardedauth.sentCode'sType,TimeoutandNextTypeand let the UI guess "приложение/SMS", so that user was told to watch for an SMS that could never arrive.All three points he raised without asking for verification were correct.
What changed
SendCodereturns aSentCodecarrying channel, code length, Telegram's own timeout and the nominated next channel./auth/phonereports the channel Telegram named; an unrecognised type is reported as unknown, never asappsendCodeResendCodecallsauth.resendCode, honours the timeout from the response, and refuses outright when Telegram nominated no next channel rather than appearing to retryauth_qr.go:auth.exportLoginToken→tg://login?token=…, polled via/auth/qr/status, withSESSION_PASSWORD_NEEDEDrouted to the existingCheck2FAso 2FA reuses the screen that already existshandleConnectusedsession.FileStorageon a container filesystem. Now Postgres, with the pending flow persisted andgetClientrestoring it before declaring a session invalidPostgresSessionStoragewas already written and unused, and referenced atelegram_sessionstable nothing in the repository created. Both tables are now created at startup.Not claimed
Whether our
api_idfell under a silent block. The symptoms match indexit#79, but there is no confirmation from our side — and until this branch,resendwas the wrong call anyway, soSEND_CODE_UNAVAILABLEwould never have surfaced.Verification
go build ./...,go vet ./internal/...,go test ./internal/telegram/— all green. Tests cover the delivery-type mapping, that an unknown type is never reported asapp, and that a resend with no next channel refuses.Not exercised against live Telegram: the QR scan and the DC-migration path need a real account.
🤖 Generated with Claude Code