feat(ui): record the SDK load outcome in the launch diagnostic
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Has been skipped
CI / integration (pull_request) Has been skipped
CI / ui (pull_request) Successful in 55s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m16s
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Has been skipped
CI / integration (pull_request) Has been skipped
CI / ui (pull_request) Successful in 55s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m16s
The diagnostic showed only sdk: yes/no (window.Telegram presence), not why the SDK was absent. Capture how the dynamic telegram-web-app.js load resolved — present / loaded / no-webapp / error / timeout — and surface it as "sdk-load: <outcome>". error/timeout pinpoint a blocked or hanging telegram.org (the prime suspect for an empty launch); no-webapp a loaded-but-broken script. loadTelegramSDK records the outcome (telegramSdkOutcome); collectTelegramDiag carries it into the screen. Unit tests cover each outcome; the blocked-script e2e now asserts sdk-load: error.
This commit is contained in:
@@ -131,5 +131,6 @@ test('a blocked telegram-web-app.js does not hang the diagnostic screen', async
|
||||
await page.goto('/telegram/');
|
||||
|
||||
await expect(page.getByRole('button', { name: 'Share' })).toBeVisible();
|
||||
await expect(page.getByText('sdk: no')).toBeVisible();
|
||||
// The diagnostic names the load outcome: a failed fetch reads as sdk-load: error.
|
||||
await expect(page.getByText('sdk-load: error')).toBeVisible();
|
||||
});
|
||||
|
||||
Reference in New Issue
Block a user