WebApp.requestWriteAccess() callback never fires on second invocation (page reload / repeated call)

[AgentBelfort]

Steps to reproduce

Open a Mini App in Telegram Desktop. The Mini App calls Telegram.WebApp.requestWriteAccess(callback) early during initialization.
The permission modal appears. Either dismiss it without explicit answer, or grant/deny normally - both reproduce the issue.
Reload the Mini App page (Ctrl+R / "Reload page" from the three-dots menu), OR call requestWriteAccess a second time within the same session.
On the second call, the SDK logs to the JS console:

[Telegram.WebApp] Write access is already requested
and the callback passed to requestWriteAccess is never invoked.

Expected behaviour

The callback should be invoked with a boolean result on every call, regardless of whether the request was suppressed due to throttling, an existing permission, or any other internal state. Either of these would be acceptable:

Invoke the callback synchronously with true if the user has previously granted access (allows_write_to_pm: true in initData).
Invoke the callback with false if the request is suppressed (throttled / already pending).
Pass through and re-show the modal.

Currently the callback is silently dropped, which makes it impossible for a Mini App to know whether to wait for a response or proceed.

Actual behaviour

Callback is never called. Any await new Promise(resolve => Telegram.WebApp.requestWriteAccess(resolve)) pattern hangs forever, blocking the rest of module initialization on async paths. No error is thrown, no event is dispatched, no rejection occurs — the promise simply never settles.

Operating system

Windows 11

Version of Telegram Desktop

Telegram Desktop (latest stable), Telegram.WebApp.version === "9.6"

Installation source

Static binary from official website

Crash ID

No response

Logs

[github-actions]

Sorry, but according to the version you specify in this issue, you are using the Telegram for macOS, not the Telegram Desktop.
You can report your issue to the group or to the repository of Telegram for macOS.

If I made a mistake and closed your issue wrongly, please reopen it. Thanks!

[AgentBelfort]

Это Telegram Desktop дял Windows, глупый бот :D

[AgentBelfort]

so cool

[AgentBelfort]

A few important clarifications to the report, because the original steps to reproduce make it sound like the bug is 100% reproducible - and it isn't.
The bug occurs intermittently. In the vast majority of cases, requestWriteAccess works correctly - either the callback is invoked, or the modal is shown. Other users of my Mini App see this issue rarely, but it does happen, and each occurrence leaves the UI completely broken.
The scenario I observed personally:

I opened the Mini App on Telegram Desktop (Windows 11). The page loaded visually (HTML/CSS rendered), but JS initialization hung on await new Promise(resolve => Telegram.WebApp.requestWriteAccess(resolve)). The callback was never invoked, even after a long wait.
The permission modal asking for write access was never shown. The SDK neither displayed the modal nor invoked the callback - it just silently swallowed the call. The console contained several messages from the Telegram SDK, including [Telegram.WebApp] Write access is already requested.
allows_write_to_pm in initData was true at the time (permission had been granted earlier from another client).
Repeated reloads within the same session did not help - the behavior persisted. The only way to recover was to remove the requestWriteAccess call from the code entirely - after that, the Mini App started working again.
On Android, the same Mini App with the same code handles requestWriteAccess correctly: the callback fires, no hangs. The problem reproduced only on Telegram Desktop under Windows.

So this doesn't look like pure throttling (with throttling, the callback would fire quickly with false or a cached result) - it looks more like a state the SDK occasionally enters and cannot exit until the Mini App is fully closed, with neither the modal nor the callback being delivered. I couldn't reproduce it on demand, but during my session the behavior was sticky: neither reloads nor repeated calls revived the callback.
Even a low frequency of this bug (say, 1 in 1000 users) at Mini Apps scale means a noticeable number of "silently broken" sessions that are impossible to detect via standard error tracking - no error is thrown, the async flow just quietly stalls.
Happy to collect additional data on the next reproduction if the team needs it.

[BaHeK1994]

Actual on Ubuntu 24.04, Telegram Desktop 6.8.3 beta

Dialog requestWriteAccess not opened.