Home Explore Help
Sign In
txlyre
Repositories Public Activity

txlyre synced commits to dependabot/npm_and_yarn/frontend/vitest/coverage-v8-5.0.1 at txlyre/3x-ui from mirror

  • 4d2f005fcc chore(deps-dev): bump @vitest/coverage-v8 in /frontend Bumps [@vitest/coverage-v8](https://github.com/vitest-dev/vitest/tree/HEAD/packages/coverage-v8) from 5.0.0 to 5.0.1. - [Release notes](https://github.com/vitest-dev/vitest/releases) - [Changelog](https://github.com/vitest-dev/vitest/blob/main/docs/releases.md) - [Commits](https://github.com/vitest-dev/vitest/commits/v5.0.1/packages/coverage-v8) --- updated-dependencies: - dependency-name: "@vitest/coverage-v8" dependency-version: 5.0.1 dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
  • 95f19b192f fix(nodes): stop a restarting panel from reporting itself as down Adding a node fails right after that node's panel restarts. nodes/add probes the node's /panel/api/server/status first, and that endpoint returns whatever the @2s ticker last sampled - nil until the first tick lands, so the master reads a healthy panel as unreachable and rejects it with "Add node (remote returned success=false: )", an error whose message is empty because the node answered success with a null obj. The window is far wider than one tick: GetStatus resolved the public IPv4/IPv6 addresses inline and held s.mu across every lookup, so a box with no IPv6 route spent 3s per service - about 15s of nil status after each restart, and the same stall on a fresh panel's first sample. - status now answers from CurrentStatus, which samples on demand when the ticker has not run yet instead of returning a null obj - the public-IP lookups run in the background and outside s.mu, so a status sample never waits on them - probe tells "no status yet" apart from a genuine success=false, so the master's error says something when it meets an older node
  • 1c0ce80e8e fix(ci): keep a refused Claude credential from reddening a pull request (#6585) * fix(ci): keep a refused Claude credential from reddening a PR An expired subscription ends the claude-code-action step with exit 0, so the classifier that exists for "the API refused this run" never sees it -- its condition is a failed step -- and the final "posted nothing" step reddens the pull request although nothing is wrong with the repository. Verified against five real runs (35159059540, 35184688775, 35185722358, 35186543654, 35187380192): step 8 success, step 10 found no cause, step 11 failure, transcript {"error":"oauth_org_not_allowed"} plus a result entry with api_error_status 403. A usage-limited run carries 429 and a rejected rate_limit_event, and a real review carries is_error false with no status, so the 401/403 test fires on the refused credential alone. * fix(ci): stop a refused credential reddening the issue analysis The same exit-0 refusal reaches this workflow's "posted no reply" check, which fails for the same reason and shows up as seven failed runs in a day. It never attaches to a pull request -- the trigger excludes them -- so this is the same step and the same 401/403 transcript test applied where the refusal lands. Reported only as a warning annotation: nothing was analysed, and there is no comment worth posting about a credential the maintainer has to renew.
  • f8db7f6c29 fix(nodes): say which half of node mTLS failed, and say it as an error (#6565) * fix(nodes): say which half of node mTLS failed, and say it as an error A configured client CA bundle that will not parse produced the same warning as a settings read that failed, and both read as though mTLS were merely unavailable. It is not: the node API silently stops accepting client certificates, callers fall back to a bearer token or lose their only credential, and the one line saying so is a warning at boot. Report it at error level, and distinguish the two causes rather than attributing a storage fault to the operator's certificate bundle. NodeMtlsClientCAPool now tags the parse failure with ErrNodeMtlsTrustBundleInvalid; its message text is unchanged, so anything matching on the existing string still matches. Startup is deliberately left alone. Refusing to boot was considered and rejected: the bundle is one of two equal credentials here, a panel that will not start takes the proxies and the subscription server with it, and bundles written before the stricter validation landed in #6188 are already stored, editable only through the panel that would no longer come up. The tests pin the tag on an unusable bundle and its absence on an unset one; without the tag the first goes red. * test(nodes): drop a duplicate node mTLS trust-bundle test TestNodeMtlsClientCAPoolLeavesUnsetBundleUntagged asserted only that an unset nodeMtlsClientCAPem yields (nil, nil). That path returns before the line the sentinel change touched, so the test was green with and without ErrNodeMtlsTrustBundleInvalid, and TestNodeMtlsClientCAPool already pins the same two assertions on the same fixture. A test that passes either way certifies nothing and then gets cited as coverage for the sentinel. TestNodeMtlsClientCAPoolTagsAnInvalidBundle, which does go red without the sentinel, stays as the regression guard. --------- Co-authored-by: Sanaei <[email protected]>
  • 536f9a6338 fix(tgbot): localize QR caption via I18nBot (#6564) * fix(panel): accept 2FA codes from adjacent TOTP windows CheckUser compared only gotp.Now(), so a code submitted at the end of its 30s window (or with slight client/server clock drift) failed with 'invalid 2fa code', while the immediate retry in the next window succeeded. Accept current +/-1 window, the standard TOTP skew tolerance. Fixes MHSanaei/3x-ui#6535 * fix(panel): share TOTP skew tolerance with VerifyTwoFactorCode Move the +/-1 window helper to internal/util/totp so both 2FA acceptance points use it: login (CheckUser) and disable/rebind plus username/password changes (VerifyTwoFactorCode). Also shrink comments to the 2-line house rule and anchor the unit test mid-window to avoid a step-boundary flake. Addresses review on #6546 (MEDIUM + 2 LOWs). * fix(tgbot): localize QR caption via I18nBot sendClientQRLinks hardcoded English 'QRCode for client <email>:', bypassing I18nBot, so non-English bot languages (e.g. ru-RU) still got English. Add tgbot.answers.qrCodeForClient key with Email param in all 13 locales and route the caption through I18nBot. Fixes MHSanaei/3x-ui#6562 * fix(tgbot): repair locale JSON syntax, harden QR i18n test - Add missing separators so all 13 locale files parse again. - Rewrite the regression test to read the real shipped files (fails on malformed JSON or missing key). - Add TestTgbotLocalesQrKeyValid covering every locale file. * chore(tgbot): drop QR caption tests that cannot catch the bug TestQRCodeForClientLocalizes never calls sendClientQRLinks: it registers two messages in a synthetic bundle and asserts on I18nBot, a passthrough to go-i18n. With the tgbot_client.go line reverted to the hardcoded English caption, both it and TestTgbotLocalesQrKeyValid still pass, so neither certifies the fix. The malformed-locale class they were added for is already pinned twice: the discord package's TestMain loads every translation file through locale.InitLocalizer and panics on invalid JSON, and frontend/src/test/i18n-dead-keys.test.ts parses all 13 locales and checks each carries the en-US key set. Both go red on the #6564 syntax error this PR first shipped. --------- Co-authored-by: sdhfsl <[email protected]> Co-authored-by: Sanaei <[email protected]>
  • View comparison for these 10 commits »

3 hours ago

txlyre synced new reference dependabot/npm_and_yarn/frontend/vitest/coverage-v8-5.0.1 to txlyre/3x-ui from mirror

3 hours ago

txlyre synced commits to dependabot/npm_and_yarn/frontend/vitest/browser-playwright-5.0.1 at txlyre/3x-ui from mirror

  • 2a0c4723d1 chore(deps-dev): bump @vitest/browser-playwright in /frontend Bumps [@vitest/browser-playwright](https://github.com/vitest-dev/vitest/tree/HEAD/packages/browser-playwright) from 5.0.0 to 5.0.1. - [Release notes](https://github.com/vitest-dev/vitest/releases) - [Changelog](https://github.com/vitest-dev/vitest/blob/main/docs/releases.md) - [Commits](https://github.com/vitest-dev/vitest/commits/v5.0.1/packages/browser-playwright) --- updated-dependencies: - dependency-name: "@vitest/browser-playwright" dependency-version: 5.0.1 dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
  • 95f19b192f fix(nodes): stop a restarting panel from reporting itself as down Adding a node fails right after that node's panel restarts. nodes/add probes the node's /panel/api/server/status first, and that endpoint returns whatever the @2s ticker last sampled - nil until the first tick lands, so the master reads a healthy panel as unreachable and rejects it with "Add node (remote returned success=false: )", an error whose message is empty because the node answered success with a null obj. The window is far wider than one tick: GetStatus resolved the public IPv4/IPv6 addresses inline and held s.mu across every lookup, so a box with no IPv6 route spent 3s per service - about 15s of nil status after each restart, and the same stall on a fresh panel's first sample. - status now answers from CurrentStatus, which samples on demand when the ticker has not run yet instead of returning a null obj - the public-IP lookups run in the background and outside s.mu, so a status sample never waits on them - probe tells "no status yet" apart from a genuine success=false, so the master's error says something when it meets an older node
  • 1c0ce80e8e fix(ci): keep a refused Claude credential from reddening a pull request (#6585) * fix(ci): keep a refused Claude credential from reddening a PR An expired subscription ends the claude-code-action step with exit 0, so the classifier that exists for "the API refused this run" never sees it -- its condition is a failed step -- and the final "posted nothing" step reddens the pull request although nothing is wrong with the repository. Verified against five real runs (35159059540, 35184688775, 35185722358, 35186543654, 35187380192): step 8 success, step 10 found no cause, step 11 failure, transcript {"error":"oauth_org_not_allowed"} plus a result entry with api_error_status 403. A usage-limited run carries 429 and a rejected rate_limit_event, and a real review carries is_error false with no status, so the 401/403 test fires on the refused credential alone. * fix(ci): stop a refused credential reddening the issue analysis The same exit-0 refusal reaches this workflow's "posted no reply" check, which fails for the same reason and shows up as seven failed runs in a day. It never attaches to a pull request -- the trigger excludes them -- so this is the same step and the same 401/403 transcript test applied where the refusal lands. Reported only as a warning annotation: nothing was analysed, and there is no comment worth posting about a credential the maintainer has to renew.
  • f8db7f6c29 fix(nodes): say which half of node mTLS failed, and say it as an error (#6565) * fix(nodes): say which half of node mTLS failed, and say it as an error A configured client CA bundle that will not parse produced the same warning as a settings read that failed, and both read as though mTLS were merely unavailable. It is not: the node API silently stops accepting client certificates, callers fall back to a bearer token or lose their only credential, and the one line saying so is a warning at boot. Report it at error level, and distinguish the two causes rather than attributing a storage fault to the operator's certificate bundle. NodeMtlsClientCAPool now tags the parse failure with ErrNodeMtlsTrustBundleInvalid; its message text is unchanged, so anything matching on the existing string still matches. Startup is deliberately left alone. Refusing to boot was considered and rejected: the bundle is one of two equal credentials here, a panel that will not start takes the proxies and the subscription server with it, and bundles written before the stricter validation landed in #6188 are already stored, editable only through the panel that would no longer come up. The tests pin the tag on an unusable bundle and its absence on an unset one; without the tag the first goes red. * test(nodes): drop a duplicate node mTLS trust-bundle test TestNodeMtlsClientCAPoolLeavesUnsetBundleUntagged asserted only that an unset nodeMtlsClientCAPem yields (nil, nil). That path returns before the line the sentinel change touched, so the test was green with and without ErrNodeMtlsTrustBundleInvalid, and TestNodeMtlsClientCAPool already pins the same two assertions on the same fixture. A test that passes either way certifies nothing and then gets cited as coverage for the sentinel. TestNodeMtlsClientCAPoolTagsAnInvalidBundle, which does go red without the sentinel, stays as the regression guard. --------- Co-authored-by: Sanaei <[email protected]>
  • 536f9a6338 fix(tgbot): localize QR caption via I18nBot (#6564) * fix(panel): accept 2FA codes from adjacent TOTP windows CheckUser compared only gotp.Now(), so a code submitted at the end of its 30s window (or with slight client/server clock drift) failed with 'invalid 2fa code', while the immediate retry in the next window succeeded. Accept current +/-1 window, the standard TOTP skew tolerance. Fixes MHSanaei/3x-ui#6535 * fix(panel): share TOTP skew tolerance with VerifyTwoFactorCode Move the +/-1 window helper to internal/util/totp so both 2FA acceptance points use it: login (CheckUser) and disable/rebind plus username/password changes (VerifyTwoFactorCode). Also shrink comments to the 2-line house rule and anchor the unit test mid-window to avoid a step-boundary flake. Addresses review on #6546 (MEDIUM + 2 LOWs). * fix(tgbot): localize QR caption via I18nBot sendClientQRLinks hardcoded English 'QRCode for client <email>:', bypassing I18nBot, so non-English bot languages (e.g. ru-RU) still got English. Add tgbot.answers.qrCodeForClient key with Email param in all 13 locales and route the caption through I18nBot. Fixes MHSanaei/3x-ui#6562 * fix(tgbot): repair locale JSON syntax, harden QR i18n test - Add missing separators so all 13 locale files parse again. - Rewrite the regression test to read the real shipped files (fails on malformed JSON or missing key). - Add TestTgbotLocalesQrKeyValid covering every locale file. * chore(tgbot): drop QR caption tests that cannot catch the bug TestQRCodeForClientLocalizes never calls sendClientQRLinks: it registers two messages in a synthetic bundle and asserts on I18nBot, a passthrough to go-i18n. With the tgbot_client.go line reverted to the hardcoded English caption, both it and TestTgbotLocalesQrKeyValid still pass, so neither certifies the fix. The malformed-locale class they were added for is already pinned twice: the discord package's TestMain loads every translation file through locale.InitLocalizer and panics on invalid JSON, and frontend/src/test/i18n-dead-keys.test.ts parses all 13 locales and checks each carries the en-US key set. Both go red on the #6564 syntax error this PR first shipped. --------- Co-authored-by: sdhfsl <[email protected]> Co-authored-by: Sanaei <[email protected]>
  • View comparison for these 10 commits »

3 hours ago

txlyre synced commits to dependabot/npm_and_yarn/frontend/tanstack/react-query-5.103.1 at txlyre/3x-ui from mirror

  • c1c456a102 chore(deps): bump @tanstack/react-query in /frontend Bumps [@tanstack/react-query](https://github.com/TanStack/query/tree/HEAD/packages/react-query) from 5.102.8 to 5.103.1. - [Release notes](https://github.com/TanStack/query/releases) - [Changelog](https://github.com/TanStack/query/blob/main/packages/react-query/CHANGELOG.md) - [Commits](https://github.com/TanStack/query/commits/@tanstack/[email protected]/packages/react-query) --- updated-dependencies: - dependency-name: "@tanstack/react-query" dependency-version: 5.103.1 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]>
  • 95f19b192f fix(nodes): stop a restarting panel from reporting itself as down Adding a node fails right after that node's panel restarts. nodes/add probes the node's /panel/api/server/status first, and that endpoint returns whatever the @2s ticker last sampled - nil until the first tick lands, so the master reads a healthy panel as unreachable and rejects it with "Add node (remote returned success=false: )", an error whose message is empty because the node answered success with a null obj. The window is far wider than one tick: GetStatus resolved the public IPv4/IPv6 addresses inline and held s.mu across every lookup, so a box with no IPv6 route spent 3s per service - about 15s of nil status after each restart, and the same stall on a fresh panel's first sample. - status now answers from CurrentStatus, which samples on demand when the ticker has not run yet instead of returning a null obj - the public-IP lookups run in the background and outside s.mu, so a status sample never waits on them - probe tells "no status yet" apart from a genuine success=false, so the master's error says something when it meets an older node
  • 1c0ce80e8e fix(ci): keep a refused Claude credential from reddening a pull request (#6585) * fix(ci): keep a refused Claude credential from reddening a PR An expired subscription ends the claude-code-action step with exit 0, so the classifier that exists for "the API refused this run" never sees it -- its condition is a failed step -- and the final "posted nothing" step reddens the pull request although nothing is wrong with the repository. Verified against five real runs (35159059540, 35184688775, 35185722358, 35186543654, 35187380192): step 8 success, step 10 found no cause, step 11 failure, transcript {"error":"oauth_org_not_allowed"} plus a result entry with api_error_status 403. A usage-limited run carries 429 and a rejected rate_limit_event, and a real review carries is_error false with no status, so the 401/403 test fires on the refused credential alone. * fix(ci): stop a refused credential reddening the issue analysis The same exit-0 refusal reaches this workflow's "posted no reply" check, which fails for the same reason and shows up as seven failed runs in a day. It never attaches to a pull request -- the trigger excludes them -- so this is the same step and the same 401/403 transcript test applied where the refusal lands. Reported only as a warning annotation: nothing was analysed, and there is no comment worth posting about a credential the maintainer has to renew.
  • f8db7f6c29 fix(nodes): say which half of node mTLS failed, and say it as an error (#6565) * fix(nodes): say which half of node mTLS failed, and say it as an error A configured client CA bundle that will not parse produced the same warning as a settings read that failed, and both read as though mTLS were merely unavailable. It is not: the node API silently stops accepting client certificates, callers fall back to a bearer token or lose their only credential, and the one line saying so is a warning at boot. Report it at error level, and distinguish the two causes rather than attributing a storage fault to the operator's certificate bundle. NodeMtlsClientCAPool now tags the parse failure with ErrNodeMtlsTrustBundleInvalid; its message text is unchanged, so anything matching on the existing string still matches. Startup is deliberately left alone. Refusing to boot was considered and rejected: the bundle is one of two equal credentials here, a panel that will not start takes the proxies and the subscription server with it, and bundles written before the stricter validation landed in #6188 are already stored, editable only through the panel that would no longer come up. The tests pin the tag on an unusable bundle and its absence on an unset one; without the tag the first goes red. * test(nodes): drop a duplicate node mTLS trust-bundle test TestNodeMtlsClientCAPoolLeavesUnsetBundleUntagged asserted only that an unset nodeMtlsClientCAPem yields (nil, nil). That path returns before the line the sentinel change touched, so the test was green with and without ErrNodeMtlsTrustBundleInvalid, and TestNodeMtlsClientCAPool already pins the same two assertions on the same fixture. A test that passes either way certifies nothing and then gets cited as coverage for the sentinel. TestNodeMtlsClientCAPoolTagsAnInvalidBundle, which does go red without the sentinel, stays as the regression guard. --------- Co-authored-by: Sanaei <[email protected]>
  • 536f9a6338 fix(tgbot): localize QR caption via I18nBot (#6564) * fix(panel): accept 2FA codes from adjacent TOTP windows CheckUser compared only gotp.Now(), so a code submitted at the end of its 30s window (or with slight client/server clock drift) failed with 'invalid 2fa code', while the immediate retry in the next window succeeded. Accept current +/-1 window, the standard TOTP skew tolerance. Fixes MHSanaei/3x-ui#6535 * fix(panel): share TOTP skew tolerance with VerifyTwoFactorCode Move the +/-1 window helper to internal/util/totp so both 2FA acceptance points use it: login (CheckUser) and disable/rebind plus username/password changes (VerifyTwoFactorCode). Also shrink comments to the 2-line house rule and anchor the unit test mid-window to avoid a step-boundary flake. Addresses review on #6546 (MEDIUM + 2 LOWs). * fix(tgbot): localize QR caption via I18nBot sendClientQRLinks hardcoded English 'QRCode for client <email>:', bypassing I18nBot, so non-English bot languages (e.g. ru-RU) still got English. Add tgbot.answers.qrCodeForClient key with Email param in all 13 locales and route the caption through I18nBot. Fixes MHSanaei/3x-ui#6562 * fix(tgbot): repair locale JSON syntax, harden QR i18n test - Add missing separators so all 13 locale files parse again. - Rewrite the regression test to read the real shipped files (fails on malformed JSON or missing key). - Add TestTgbotLocalesQrKeyValid covering every locale file. * chore(tgbot): drop QR caption tests that cannot catch the bug TestQRCodeForClientLocalizes never calls sendClientQRLinks: it registers two messages in a synthetic bundle and asserts on I18nBot, a passthrough to go-i18n. With the tgbot_client.go line reverted to the hardcoded English caption, both it and TestTgbotLocalesQrKeyValid still pass, so neither certifies the fix. The malformed-locale class they were added for is already pinned twice: the discord package's TestMain loads every translation file through locale.InitLocalizer and panics on invalid JSON, and frontend/src/test/i18n-dead-keys.test.ts parses all 13 locales and checks each carries the en-US key set. Both go red on the #6564 syntax error this PR first shipped. --------- Co-authored-by: sdhfsl <[email protected]> Co-authored-by: Sanaei <[email protected]>
  • View comparison for these 10 commits »

3 hours ago

txlyre synced commits to dependabot/npm_and_yarn/frontend/oxlint-tsgolint-7.0.2002 at txlyre/3x-ui from mirror

  • 4042c98ca0 chore(deps-dev): bump oxlint-tsgolint in /frontend Bumps [oxlint-tsgolint](https://github.com/oxc-project/tsgolint) from 7.0.2001 to 7.0.2002. - [Release notes](https://github.com/oxc-project/tsgolint/releases) - [Commits](https://github.com/oxc-project/tsgolint/compare/v7.0.2001...v7.0.2002) --- updated-dependencies: - dependency-name: oxlint-tsgolint dependency-version: 7.0.2002 dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
  • 95f19b192f fix(nodes): stop a restarting panel from reporting itself as down Adding a node fails right after that node's panel restarts. nodes/add probes the node's /panel/api/server/status first, and that endpoint returns whatever the @2s ticker last sampled - nil until the first tick lands, so the master reads a healthy panel as unreachable and rejects it with "Add node (remote returned success=false: )", an error whose message is empty because the node answered success with a null obj. The window is far wider than one tick: GetStatus resolved the public IPv4/IPv6 addresses inline and held s.mu across every lookup, so a box with no IPv6 route spent 3s per service - about 15s of nil status after each restart, and the same stall on a fresh panel's first sample. - status now answers from CurrentStatus, which samples on demand when the ticker has not run yet instead of returning a null obj - the public-IP lookups run in the background and outside s.mu, so a status sample never waits on them - probe tells "no status yet" apart from a genuine success=false, so the master's error says something when it meets an older node
  • 1c0ce80e8e fix(ci): keep a refused Claude credential from reddening a pull request (#6585) * fix(ci): keep a refused Claude credential from reddening a PR An expired subscription ends the claude-code-action step with exit 0, so the classifier that exists for "the API refused this run" never sees it -- its condition is a failed step -- and the final "posted nothing" step reddens the pull request although nothing is wrong with the repository. Verified against five real runs (35159059540, 35184688775, 35185722358, 35186543654, 35187380192): step 8 success, step 10 found no cause, step 11 failure, transcript {"error":"oauth_org_not_allowed"} plus a result entry with api_error_status 403. A usage-limited run carries 429 and a rejected rate_limit_event, and a real review carries is_error false with no status, so the 401/403 test fires on the refused credential alone. * fix(ci): stop a refused credential reddening the issue analysis The same exit-0 refusal reaches this workflow's "posted no reply" check, which fails for the same reason and shows up as seven failed runs in a day. It never attaches to a pull request -- the trigger excludes them -- so this is the same step and the same 401/403 transcript test applied where the refusal lands. Reported only as a warning annotation: nothing was analysed, and there is no comment worth posting about a credential the maintainer has to renew.
  • f8db7f6c29 fix(nodes): say which half of node mTLS failed, and say it as an error (#6565) * fix(nodes): say which half of node mTLS failed, and say it as an error A configured client CA bundle that will not parse produced the same warning as a settings read that failed, and both read as though mTLS were merely unavailable. It is not: the node API silently stops accepting client certificates, callers fall back to a bearer token or lose their only credential, and the one line saying so is a warning at boot. Report it at error level, and distinguish the two causes rather than attributing a storage fault to the operator's certificate bundle. NodeMtlsClientCAPool now tags the parse failure with ErrNodeMtlsTrustBundleInvalid; its message text is unchanged, so anything matching on the existing string still matches. Startup is deliberately left alone. Refusing to boot was considered and rejected: the bundle is one of two equal credentials here, a panel that will not start takes the proxies and the subscription server with it, and bundles written before the stricter validation landed in #6188 are already stored, editable only through the panel that would no longer come up. The tests pin the tag on an unusable bundle and its absence on an unset one; without the tag the first goes red. * test(nodes): drop a duplicate node mTLS trust-bundle test TestNodeMtlsClientCAPoolLeavesUnsetBundleUntagged asserted only that an unset nodeMtlsClientCAPem yields (nil, nil). That path returns before the line the sentinel change touched, so the test was green with and without ErrNodeMtlsTrustBundleInvalid, and TestNodeMtlsClientCAPool already pins the same two assertions on the same fixture. A test that passes either way certifies nothing and then gets cited as coverage for the sentinel. TestNodeMtlsClientCAPoolTagsAnInvalidBundle, which does go red without the sentinel, stays as the regression guard. --------- Co-authored-by: Sanaei <[email protected]>
  • 536f9a6338 fix(tgbot): localize QR caption via I18nBot (#6564) * fix(panel): accept 2FA codes from adjacent TOTP windows CheckUser compared only gotp.Now(), so a code submitted at the end of its 30s window (or with slight client/server clock drift) failed with 'invalid 2fa code', while the immediate retry in the next window succeeded. Accept current +/-1 window, the standard TOTP skew tolerance. Fixes MHSanaei/3x-ui#6535 * fix(panel): share TOTP skew tolerance with VerifyTwoFactorCode Move the +/-1 window helper to internal/util/totp so both 2FA acceptance points use it: login (CheckUser) and disable/rebind plus username/password changes (VerifyTwoFactorCode). Also shrink comments to the 2-line house rule and anchor the unit test mid-window to avoid a step-boundary flake. Addresses review on #6546 (MEDIUM + 2 LOWs). * fix(tgbot): localize QR caption via I18nBot sendClientQRLinks hardcoded English 'QRCode for client <email>:', bypassing I18nBot, so non-English bot languages (e.g. ru-RU) still got English. Add tgbot.answers.qrCodeForClient key with Email param in all 13 locales and route the caption through I18nBot. Fixes MHSanaei/3x-ui#6562 * fix(tgbot): repair locale JSON syntax, harden QR i18n test - Add missing separators so all 13 locale files parse again. - Rewrite the regression test to read the real shipped files (fails on malformed JSON or missing key). - Add TestTgbotLocalesQrKeyValid covering every locale file. * chore(tgbot): drop QR caption tests that cannot catch the bug TestQRCodeForClientLocalizes never calls sendClientQRLinks: it registers two messages in a synthetic bundle and asserts on I18nBot, a passthrough to go-i18n. With the tgbot_client.go line reverted to the hardcoded English caption, both it and TestTgbotLocalesQrKeyValid still pass, so neither certifies the fix. The malformed-locale class they were added for is already pinned twice: the discord package's TestMain loads every translation file through locale.InitLocalizer and panics on invalid JSON, and frontend/src/test/i18n-dead-keys.test.ts parses all 13 locales and checks each carries the en-US key set. Both go red on the #6564 syntax error this PR first shipped. --------- Co-authored-by: sdhfsl <[email protected]> Co-authored-by: Sanaei <[email protected]>
  • View comparison for these 10 commits »

3 hours ago

txlyre synced new reference dependabot/npm_and_yarn/frontend/oxlint-tsgolint-7.0.2002 to txlyre/3x-ui from mirror

3 hours ago

txlyre synced commits to dependabot/npm_and_yarn/frontend/jsdom-30.1.0 at txlyre/3x-ui from mirror

  • f73e7ca08b chore(deps-dev): bump jsdom from 30.0.1 to 30.1.0 in /frontend Bumps [jsdom](https://github.com/jsdom/jsdom) from 30.0.1 to 30.1.0. - [Release notes](https://github.com/jsdom/jsdom/releases) - [Commits](https://github.com/jsdom/jsdom/compare/v30.0.1...v30.1.0) --- updated-dependencies: - dependency-name: jsdom dependency-version: 30.1.0 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]>
  • 95f19b192f fix(nodes): stop a restarting panel from reporting itself as down Adding a node fails right after that node's panel restarts. nodes/add probes the node's /panel/api/server/status first, and that endpoint returns whatever the @2s ticker last sampled - nil until the first tick lands, so the master reads a healthy panel as unreachable and rejects it with "Add node (remote returned success=false: )", an error whose message is empty because the node answered success with a null obj. The window is far wider than one tick: GetStatus resolved the public IPv4/IPv6 addresses inline and held s.mu across every lookup, so a box with no IPv6 route spent 3s per service - about 15s of nil status after each restart, and the same stall on a fresh panel's first sample. - status now answers from CurrentStatus, which samples on demand when the ticker has not run yet instead of returning a null obj - the public-IP lookups run in the background and outside s.mu, so a status sample never waits on them - probe tells "no status yet" apart from a genuine success=false, so the master's error says something when it meets an older node
  • 1c0ce80e8e fix(ci): keep a refused Claude credential from reddening a pull request (#6585) * fix(ci): keep a refused Claude credential from reddening a PR An expired subscription ends the claude-code-action step with exit 0, so the classifier that exists for "the API refused this run" never sees it -- its condition is a failed step -- and the final "posted nothing" step reddens the pull request although nothing is wrong with the repository. Verified against five real runs (35159059540, 35184688775, 35185722358, 35186543654, 35187380192): step 8 success, step 10 found no cause, step 11 failure, transcript {"error":"oauth_org_not_allowed"} plus a result entry with api_error_status 403. A usage-limited run carries 429 and a rejected rate_limit_event, and a real review carries is_error false with no status, so the 401/403 test fires on the refused credential alone. * fix(ci): stop a refused credential reddening the issue analysis The same exit-0 refusal reaches this workflow's "posted no reply" check, which fails for the same reason and shows up as seven failed runs in a day. It never attaches to a pull request -- the trigger excludes them -- so this is the same step and the same 401/403 transcript test applied where the refusal lands. Reported only as a warning annotation: nothing was analysed, and there is no comment worth posting about a credential the maintainer has to renew.
  • f8db7f6c29 fix(nodes): say which half of node mTLS failed, and say it as an error (#6565) * fix(nodes): say which half of node mTLS failed, and say it as an error A configured client CA bundle that will not parse produced the same warning as a settings read that failed, and both read as though mTLS were merely unavailable. It is not: the node API silently stops accepting client certificates, callers fall back to a bearer token or lose their only credential, and the one line saying so is a warning at boot. Report it at error level, and distinguish the two causes rather than attributing a storage fault to the operator's certificate bundle. NodeMtlsClientCAPool now tags the parse failure with ErrNodeMtlsTrustBundleInvalid; its message text is unchanged, so anything matching on the existing string still matches. Startup is deliberately left alone. Refusing to boot was considered and rejected: the bundle is one of two equal credentials here, a panel that will not start takes the proxies and the subscription server with it, and bundles written before the stricter validation landed in #6188 are already stored, editable only through the panel that would no longer come up. The tests pin the tag on an unusable bundle and its absence on an unset one; without the tag the first goes red. * test(nodes): drop a duplicate node mTLS trust-bundle test TestNodeMtlsClientCAPoolLeavesUnsetBundleUntagged asserted only that an unset nodeMtlsClientCAPem yields (nil, nil). That path returns before the line the sentinel change touched, so the test was green with and without ErrNodeMtlsTrustBundleInvalid, and TestNodeMtlsClientCAPool already pins the same two assertions on the same fixture. A test that passes either way certifies nothing and then gets cited as coverage for the sentinel. TestNodeMtlsClientCAPoolTagsAnInvalidBundle, which does go red without the sentinel, stays as the regression guard. --------- Co-authored-by: Sanaei <[email protected]>
  • 536f9a6338 fix(tgbot): localize QR caption via I18nBot (#6564) * fix(panel): accept 2FA codes from adjacent TOTP windows CheckUser compared only gotp.Now(), so a code submitted at the end of its 30s window (or with slight client/server clock drift) failed with 'invalid 2fa code', while the immediate retry in the next window succeeded. Accept current +/-1 window, the standard TOTP skew tolerance. Fixes MHSanaei/3x-ui#6535 * fix(panel): share TOTP skew tolerance with VerifyTwoFactorCode Move the +/-1 window helper to internal/util/totp so both 2FA acceptance points use it: login (CheckUser) and disable/rebind plus username/password changes (VerifyTwoFactorCode). Also shrink comments to the 2-line house rule and anchor the unit test mid-window to avoid a step-boundary flake. Addresses review on #6546 (MEDIUM + 2 LOWs). * fix(tgbot): localize QR caption via I18nBot sendClientQRLinks hardcoded English 'QRCode for client <email>:', bypassing I18nBot, so non-English bot languages (e.g. ru-RU) still got English. Add tgbot.answers.qrCodeForClient key with Email param in all 13 locales and route the caption through I18nBot. Fixes MHSanaei/3x-ui#6562 * fix(tgbot): repair locale JSON syntax, harden QR i18n test - Add missing separators so all 13 locale files parse again. - Rewrite the regression test to read the real shipped files (fails on malformed JSON or missing key). - Add TestTgbotLocalesQrKeyValid covering every locale file. * chore(tgbot): drop QR caption tests that cannot catch the bug TestQRCodeForClientLocalizes never calls sendClientQRLinks: it registers two messages in a synthetic bundle and asserts on I18nBot, a passthrough to go-i18n. With the tgbot_client.go line reverted to the hardcoded English caption, both it and TestTgbotLocalesQrKeyValid still pass, so neither certifies the fix. The malformed-locale class they were added for is already pinned twice: the discord package's TestMain loads every translation file through locale.InitLocalizer and panics on invalid JSON, and frontend/src/test/i18n-dead-keys.test.ts parses all 13 locales and checks each carries the en-US key set. Both go red on the #6564 syntax error this PR first shipped. --------- Co-authored-by: sdhfsl <[email protected]> Co-authored-by: Sanaei <[email protected]>
  • View comparison for these 10 commits »

3 hours ago

txlyre synced new reference dependabot/npm_and_yarn/frontend/jsdom-30.1.0 to txlyre/3x-ui from mirror

3 hours ago

txlyre synced commits to dependabot/go_modules/google.golang.org/grpc-1.84.0 at txlyre/3x-ui from mirror

  • 8045b6fa91 chore(deps): bump google.golang.org/grpc from 1.83.2 to 1.84.0 Bumps [google.golang.org/grpc](https://github.com/grpc/grpc-go) from 1.83.2 to 1.84.0. - [Release notes](https://github.com/grpc/grpc-go/releases) - [Commits](https://github.com/grpc/grpc-go/compare/v1.83.2...v1.84.0) --- updated-dependencies: - dependency-name: google.golang.org/grpc dependency-version: 1.84.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]>
  • 95f19b192f fix(nodes): stop a restarting panel from reporting itself as down Adding a node fails right after that node's panel restarts. nodes/add probes the node's /panel/api/server/status first, and that endpoint returns whatever the @2s ticker last sampled - nil until the first tick lands, so the master reads a healthy panel as unreachable and rejects it with "Add node (remote returned success=false: )", an error whose message is empty because the node answered success with a null obj. The window is far wider than one tick: GetStatus resolved the public IPv4/IPv6 addresses inline and held s.mu across every lookup, so a box with no IPv6 route spent 3s per service - about 15s of nil status after each restart, and the same stall on a fresh panel's first sample. - status now answers from CurrentStatus, which samples on demand when the ticker has not run yet instead of returning a null obj - the public-IP lookups run in the background and outside s.mu, so a status sample never waits on them - probe tells "no status yet" apart from a genuine success=false, so the master's error says something when it meets an older node
  • 1c0ce80e8e fix(ci): keep a refused Claude credential from reddening a pull request (#6585) * fix(ci): keep a refused Claude credential from reddening a PR An expired subscription ends the claude-code-action step with exit 0, so the classifier that exists for "the API refused this run" never sees it -- its condition is a failed step -- and the final "posted nothing" step reddens the pull request although nothing is wrong with the repository. Verified against five real runs (35159059540, 35184688775, 35185722358, 35186543654, 35187380192): step 8 success, step 10 found no cause, step 11 failure, transcript {"error":"oauth_org_not_allowed"} plus a result entry with api_error_status 403. A usage-limited run carries 429 and a rejected rate_limit_event, and a real review carries is_error false with no status, so the 401/403 test fires on the refused credential alone. * fix(ci): stop a refused credential reddening the issue analysis The same exit-0 refusal reaches this workflow's "posted no reply" check, which fails for the same reason and shows up as seven failed runs in a day. It never attaches to a pull request -- the trigger excludes them -- so this is the same step and the same 401/403 transcript test applied where the refusal lands. Reported only as a warning annotation: nothing was analysed, and there is no comment worth posting about a credential the maintainer has to renew.
  • f8db7f6c29 fix(nodes): say which half of node mTLS failed, and say it as an error (#6565) * fix(nodes): say which half of node mTLS failed, and say it as an error A configured client CA bundle that will not parse produced the same warning as a settings read that failed, and both read as though mTLS were merely unavailable. It is not: the node API silently stops accepting client certificates, callers fall back to a bearer token or lose their only credential, and the one line saying so is a warning at boot. Report it at error level, and distinguish the two causes rather than attributing a storage fault to the operator's certificate bundle. NodeMtlsClientCAPool now tags the parse failure with ErrNodeMtlsTrustBundleInvalid; its message text is unchanged, so anything matching on the existing string still matches. Startup is deliberately left alone. Refusing to boot was considered and rejected: the bundle is one of two equal credentials here, a panel that will not start takes the proxies and the subscription server with it, and bundles written before the stricter validation landed in #6188 are already stored, editable only through the panel that would no longer come up. The tests pin the tag on an unusable bundle and its absence on an unset one; without the tag the first goes red. * test(nodes): drop a duplicate node mTLS trust-bundle test TestNodeMtlsClientCAPoolLeavesUnsetBundleUntagged asserted only that an unset nodeMtlsClientCAPem yields (nil, nil). That path returns before the line the sentinel change touched, so the test was green with and without ErrNodeMtlsTrustBundleInvalid, and TestNodeMtlsClientCAPool already pins the same two assertions on the same fixture. A test that passes either way certifies nothing and then gets cited as coverage for the sentinel. TestNodeMtlsClientCAPoolTagsAnInvalidBundle, which does go red without the sentinel, stays as the regression guard. --------- Co-authored-by: Sanaei <[email protected]>
  • 536f9a6338 fix(tgbot): localize QR caption via I18nBot (#6564) * fix(panel): accept 2FA codes from adjacent TOTP windows CheckUser compared only gotp.Now(), so a code submitted at the end of its 30s window (or with slight client/server clock drift) failed with 'invalid 2fa code', while the immediate retry in the next window succeeded. Accept current +/-1 window, the standard TOTP skew tolerance. Fixes MHSanaei/3x-ui#6535 * fix(panel): share TOTP skew tolerance with VerifyTwoFactorCode Move the +/-1 window helper to internal/util/totp so both 2FA acceptance points use it: login (CheckUser) and disable/rebind plus username/password changes (VerifyTwoFactorCode). Also shrink comments to the 2-line house rule and anchor the unit test mid-window to avoid a step-boundary flake. Addresses review on #6546 (MEDIUM + 2 LOWs). * fix(tgbot): localize QR caption via I18nBot sendClientQRLinks hardcoded English 'QRCode for client <email>:', bypassing I18nBot, so non-English bot languages (e.g. ru-RU) still got English. Add tgbot.answers.qrCodeForClient key with Email param in all 13 locales and route the caption through I18nBot. Fixes MHSanaei/3x-ui#6562 * fix(tgbot): repair locale JSON syntax, harden QR i18n test - Add missing separators so all 13 locale files parse again. - Rewrite the regression test to read the real shipped files (fails on malformed JSON or missing key). - Add TestTgbotLocalesQrKeyValid covering every locale file. * chore(tgbot): drop QR caption tests that cannot catch the bug TestQRCodeForClientLocalizes never calls sendClientQRLinks: it registers two messages in a synthetic bundle and asserts on I18nBot, a passthrough to go-i18n. With the tgbot_client.go line reverted to the hardcoded English caption, both it and TestTgbotLocalesQrKeyValid still pass, so neither certifies the fix. The malformed-locale class they were added for is already pinned twice: the discord package's TestMain loads every translation file through locale.InitLocalizer and panics on invalid JSON, and frontend/src/test/i18n-dead-keys.test.ts parses all 13 locales and checks each carries the en-US key set. Both go red on the #6564 syntax error this PR first shipped. --------- Co-authored-by: sdhfsl <[email protected]> Co-authored-by: Sanaei <[email protected]>
  • View comparison for these 10 commits »

3 hours ago

txlyre synced new reference dependabot/go_modules/google.golang.org/grpc-1.84.0 to txlyre/3x-ui from mirror

3 hours ago

txlyre synced commits to dependabot/go_modules/go.uber.org/atomic-1.12.0 at txlyre/3x-ui from mirror

  • fbfddabdb0 chore(deps): bump go.uber.org/atomic from 1.11.0 to 1.12.0 Bumps [go.uber.org/atomic](https://github.com/uber-go/atomic) from 1.11.0 to 1.12.0. - [Release notes](https://github.com/uber-go/atomic/releases) - [Changelog](https://github.com/uber-go/atomic/blob/master/CHANGELOG.md) - [Commits](https://github.com/uber-go/atomic/compare/v1.11.0...v1.12.0) --- updated-dependencies: - dependency-name: go.uber.org/atomic dependency-version: 1.12.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]>
  • 95f19b192f fix(nodes): stop a restarting panel from reporting itself as down Adding a node fails right after that node's panel restarts. nodes/add probes the node's /panel/api/server/status first, and that endpoint returns whatever the @2s ticker last sampled - nil until the first tick lands, so the master reads a healthy panel as unreachable and rejects it with "Add node (remote returned success=false: )", an error whose message is empty because the node answered success with a null obj. The window is far wider than one tick: GetStatus resolved the public IPv4/IPv6 addresses inline and held s.mu across every lookup, so a box with no IPv6 route spent 3s per service - about 15s of nil status after each restart, and the same stall on a fresh panel's first sample. - status now answers from CurrentStatus, which samples on demand when the ticker has not run yet instead of returning a null obj - the public-IP lookups run in the background and outside s.mu, so a status sample never waits on them - probe tells "no status yet" apart from a genuine success=false, so the master's error says something when it meets an older node
  • 1c0ce80e8e fix(ci): keep a refused Claude credential from reddening a pull request (#6585) * fix(ci): keep a refused Claude credential from reddening a PR An expired subscription ends the claude-code-action step with exit 0, so the classifier that exists for "the API refused this run" never sees it -- its condition is a failed step -- and the final "posted nothing" step reddens the pull request although nothing is wrong with the repository. Verified against five real runs (35159059540, 35184688775, 35185722358, 35186543654, 35187380192): step 8 success, step 10 found no cause, step 11 failure, transcript {"error":"oauth_org_not_allowed"} plus a result entry with api_error_status 403. A usage-limited run carries 429 and a rejected rate_limit_event, and a real review carries is_error false with no status, so the 401/403 test fires on the refused credential alone. * fix(ci): stop a refused credential reddening the issue analysis The same exit-0 refusal reaches this workflow's "posted no reply" check, which fails for the same reason and shows up as seven failed runs in a day. It never attaches to a pull request -- the trigger excludes them -- so this is the same step and the same 401/403 transcript test applied where the refusal lands. Reported only as a warning annotation: nothing was analysed, and there is no comment worth posting about a credential the maintainer has to renew.
  • f8db7f6c29 fix(nodes): say which half of node mTLS failed, and say it as an error (#6565) * fix(nodes): say which half of node mTLS failed, and say it as an error A configured client CA bundle that will not parse produced the same warning as a settings read that failed, and both read as though mTLS were merely unavailable. It is not: the node API silently stops accepting client certificates, callers fall back to a bearer token or lose their only credential, and the one line saying so is a warning at boot. Report it at error level, and distinguish the two causes rather than attributing a storage fault to the operator's certificate bundle. NodeMtlsClientCAPool now tags the parse failure with ErrNodeMtlsTrustBundleInvalid; its message text is unchanged, so anything matching on the existing string still matches. Startup is deliberately left alone. Refusing to boot was considered and rejected: the bundle is one of two equal credentials here, a panel that will not start takes the proxies and the subscription server with it, and bundles written before the stricter validation landed in #6188 are already stored, editable only through the panel that would no longer come up. The tests pin the tag on an unusable bundle and its absence on an unset one; without the tag the first goes red. * test(nodes): drop a duplicate node mTLS trust-bundle test TestNodeMtlsClientCAPoolLeavesUnsetBundleUntagged asserted only that an unset nodeMtlsClientCAPem yields (nil, nil). That path returns before the line the sentinel change touched, so the test was green with and without ErrNodeMtlsTrustBundleInvalid, and TestNodeMtlsClientCAPool already pins the same two assertions on the same fixture. A test that passes either way certifies nothing and then gets cited as coverage for the sentinel. TestNodeMtlsClientCAPoolTagsAnInvalidBundle, which does go red without the sentinel, stays as the regression guard. --------- Co-authored-by: Sanaei <[email protected]>
  • 536f9a6338 fix(tgbot): localize QR caption via I18nBot (#6564) * fix(panel): accept 2FA codes from adjacent TOTP windows CheckUser compared only gotp.Now(), so a code submitted at the end of its 30s window (or with slight client/server clock drift) failed with 'invalid 2fa code', while the immediate retry in the next window succeeded. Accept current +/-1 window, the standard TOTP skew tolerance. Fixes MHSanaei/3x-ui#6535 * fix(panel): share TOTP skew tolerance with VerifyTwoFactorCode Move the +/-1 window helper to internal/util/totp so both 2FA acceptance points use it: login (CheckUser) and disable/rebind plus username/password changes (VerifyTwoFactorCode). Also shrink comments to the 2-line house rule and anchor the unit test mid-window to avoid a step-boundary flake. Addresses review on #6546 (MEDIUM + 2 LOWs). * fix(tgbot): localize QR caption via I18nBot sendClientQRLinks hardcoded English 'QRCode for client <email>:', bypassing I18nBot, so non-English bot languages (e.g. ru-RU) still got English. Add tgbot.answers.qrCodeForClient key with Email param in all 13 locales and route the caption through I18nBot. Fixes MHSanaei/3x-ui#6562 * fix(tgbot): repair locale JSON syntax, harden QR i18n test - Add missing separators so all 13 locale files parse again. - Rewrite the regression test to read the real shipped files (fails on malformed JSON or missing key). - Add TestTgbotLocalesQrKeyValid covering every locale file. * chore(tgbot): drop QR caption tests that cannot catch the bug TestQRCodeForClientLocalizes never calls sendClientQRLinks: it registers two messages in a synthetic bundle and asserts on I18nBot, a passthrough to go-i18n. With the tgbot_client.go line reverted to the hardcoded English caption, both it and TestTgbotLocalesQrKeyValid still pass, so neither certifies the fix. The malformed-locale class they were added for is already pinned twice: the discord package's TestMain loads every translation file through locale.InitLocalizer and panics on invalid JSON, and frontend/src/test/i18n-dead-keys.test.ts parses all 13 locales and checks each carries the en-US key set. Both go red on the #6564 syntax error this PR first shipped. --------- Co-authored-by: sdhfsl <[email protected]> Co-authored-by: Sanaei <[email protected]>
  • View comparison for these 10 commits »

3 hours ago

txlyre synced new reference dependabot/go_modules/go.uber.org/atomic-1.12.0 to txlyre/3x-ui from mirror

3 hours ago

txlyre synced commits to dependabot/go_modules/github.com/go-playground/validator/v10-10.30.5 at txlyre/3x-ui from mirror

  • 979a23fbce chore(deps): bump github.com/go-playground/validator/v10 Bumps [github.com/go-playground/validator/v10](https://github.com/go-playground/validator) from 10.30.4 to 10.30.5. - [Release notes](https://github.com/go-playground/validator/releases) - [Commits](https://github.com/go-playground/validator/compare/v10.30.4...v10.30.5) --- updated-dependencies: - dependency-name: github.com/go-playground/validator/v10 dependency-version: 10.30.5 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
  • 95f19b192f fix(nodes): stop a restarting panel from reporting itself as down Adding a node fails right after that node's panel restarts. nodes/add probes the node's /panel/api/server/status first, and that endpoint returns whatever the @2s ticker last sampled - nil until the first tick lands, so the master reads a healthy panel as unreachable and rejects it with "Add node (remote returned success=false: )", an error whose message is empty because the node answered success with a null obj. The window is far wider than one tick: GetStatus resolved the public IPv4/IPv6 addresses inline and held s.mu across every lookup, so a box with no IPv6 route spent 3s per service - about 15s of nil status after each restart, and the same stall on a fresh panel's first sample. - status now answers from CurrentStatus, which samples on demand when the ticker has not run yet instead of returning a null obj - the public-IP lookups run in the background and outside s.mu, so a status sample never waits on them - probe tells "no status yet" apart from a genuine success=false, so the master's error says something when it meets an older node
  • 1c0ce80e8e fix(ci): keep a refused Claude credential from reddening a pull request (#6585) * fix(ci): keep a refused Claude credential from reddening a PR An expired subscription ends the claude-code-action step with exit 0, so the classifier that exists for "the API refused this run" never sees it -- its condition is a failed step -- and the final "posted nothing" step reddens the pull request although nothing is wrong with the repository. Verified against five real runs (35159059540, 35184688775, 35185722358, 35186543654, 35187380192): step 8 success, step 10 found no cause, step 11 failure, transcript {"error":"oauth_org_not_allowed"} plus a result entry with api_error_status 403. A usage-limited run carries 429 and a rejected rate_limit_event, and a real review carries is_error false with no status, so the 401/403 test fires on the refused credential alone. * fix(ci): stop a refused credential reddening the issue analysis The same exit-0 refusal reaches this workflow's "posted no reply" check, which fails for the same reason and shows up as seven failed runs in a day. It never attaches to a pull request -- the trigger excludes them -- so this is the same step and the same 401/403 transcript test applied where the refusal lands. Reported only as a warning annotation: nothing was analysed, and there is no comment worth posting about a credential the maintainer has to renew.
  • f8db7f6c29 fix(nodes): say which half of node mTLS failed, and say it as an error (#6565) * fix(nodes): say which half of node mTLS failed, and say it as an error A configured client CA bundle that will not parse produced the same warning as a settings read that failed, and both read as though mTLS were merely unavailable. It is not: the node API silently stops accepting client certificates, callers fall back to a bearer token or lose their only credential, and the one line saying so is a warning at boot. Report it at error level, and distinguish the two causes rather than attributing a storage fault to the operator's certificate bundle. NodeMtlsClientCAPool now tags the parse failure with ErrNodeMtlsTrustBundleInvalid; its message text is unchanged, so anything matching on the existing string still matches. Startup is deliberately left alone. Refusing to boot was considered and rejected: the bundle is one of two equal credentials here, a panel that will not start takes the proxies and the subscription server with it, and bundles written before the stricter validation landed in #6188 are already stored, editable only through the panel that would no longer come up. The tests pin the tag on an unusable bundle and its absence on an unset one; without the tag the first goes red. * test(nodes): drop a duplicate node mTLS trust-bundle test TestNodeMtlsClientCAPoolLeavesUnsetBundleUntagged asserted only that an unset nodeMtlsClientCAPem yields (nil, nil). That path returns before the line the sentinel change touched, so the test was green with and without ErrNodeMtlsTrustBundleInvalid, and TestNodeMtlsClientCAPool already pins the same two assertions on the same fixture. A test that passes either way certifies nothing and then gets cited as coverage for the sentinel. TestNodeMtlsClientCAPoolTagsAnInvalidBundle, which does go red without the sentinel, stays as the regression guard. --------- Co-authored-by: Sanaei <[email protected]>
  • 536f9a6338 fix(tgbot): localize QR caption via I18nBot (#6564) * fix(panel): accept 2FA codes from adjacent TOTP windows CheckUser compared only gotp.Now(), so a code submitted at the end of its 30s window (or with slight client/server clock drift) failed with 'invalid 2fa code', while the immediate retry in the next window succeeded. Accept current +/-1 window, the standard TOTP skew tolerance. Fixes MHSanaei/3x-ui#6535 * fix(panel): share TOTP skew tolerance with VerifyTwoFactorCode Move the +/-1 window helper to internal/util/totp so both 2FA acceptance points use it: login (CheckUser) and disable/rebind plus username/password changes (VerifyTwoFactorCode). Also shrink comments to the 2-line house rule and anchor the unit test mid-window to avoid a step-boundary flake. Addresses review on #6546 (MEDIUM + 2 LOWs). * fix(tgbot): localize QR caption via I18nBot sendClientQRLinks hardcoded English 'QRCode for client <email>:', bypassing I18nBot, so non-English bot languages (e.g. ru-RU) still got English. Add tgbot.answers.qrCodeForClient key with Email param in all 13 locales and route the caption through I18nBot. Fixes MHSanaei/3x-ui#6562 * fix(tgbot): repair locale JSON syntax, harden QR i18n test - Add missing separators so all 13 locale files parse again. - Rewrite the regression test to read the real shipped files (fails on malformed JSON or missing key). - Add TestTgbotLocalesQrKeyValid covering every locale file. * chore(tgbot): drop QR caption tests that cannot catch the bug TestQRCodeForClientLocalizes never calls sendClientQRLinks: it registers two messages in a synthetic bundle and asserts on I18nBot, a passthrough to go-i18n. With the tgbot_client.go line reverted to the hardcoded English caption, both it and TestTgbotLocalesQrKeyValid still pass, so neither certifies the fix. The malformed-locale class they were added for is already pinned twice: the discord package's TestMain loads every translation file through locale.InitLocalizer and panics on invalid JSON, and frontend/src/test/i18n-dead-keys.test.ts parses all 13 locales and checks each carries the en-US key set. Both go red on the #6564 syntax error this PR first shipped. --------- Co-authored-by: sdhfsl <[email protected]> Co-authored-by: Sanaei <[email protected]>
  • View comparison for these 10 commits »

3 hours ago

txlyre synced commits to dependabot/go_modules/github.com/gin-contrib/sessions-1.1.2 at txlyre/3x-ui from mirror

  • 9a3240533d chore(deps): bump github.com/gin-contrib/sessions from 1.1.1 to 1.1.2 Bumps [github.com/gin-contrib/sessions](https://github.com/gin-contrib/sessions) from 1.1.1 to 1.1.2. - [Release notes](https://github.com/gin-contrib/sessions/releases) - [Commits](https://github.com/gin-contrib/sessions/compare/v1.1.1...v1.1.2) --- updated-dependencies: - dependency-name: github.com/gin-contrib/sessions dependency-version: 1.1.2 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
  • 95f19b192f fix(nodes): stop a restarting panel from reporting itself as down Adding a node fails right after that node's panel restarts. nodes/add probes the node's /panel/api/server/status first, and that endpoint returns whatever the @2s ticker last sampled - nil until the first tick lands, so the master reads a healthy panel as unreachable and rejects it with "Add node (remote returned success=false: )", an error whose message is empty because the node answered success with a null obj. The window is far wider than one tick: GetStatus resolved the public IPv4/IPv6 addresses inline and held s.mu across every lookup, so a box with no IPv6 route spent 3s per service - about 15s of nil status after each restart, and the same stall on a fresh panel's first sample. - status now answers from CurrentStatus, which samples on demand when the ticker has not run yet instead of returning a null obj - the public-IP lookups run in the background and outside s.mu, so a status sample never waits on them - probe tells "no status yet" apart from a genuine success=false, so the master's error says something when it meets an older node
  • 1c0ce80e8e fix(ci): keep a refused Claude credential from reddening a pull request (#6585) * fix(ci): keep a refused Claude credential from reddening a PR An expired subscription ends the claude-code-action step with exit 0, so the classifier that exists for "the API refused this run" never sees it -- its condition is a failed step -- and the final "posted nothing" step reddens the pull request although nothing is wrong with the repository. Verified against five real runs (35159059540, 35184688775, 35185722358, 35186543654, 35187380192): step 8 success, step 10 found no cause, step 11 failure, transcript {"error":"oauth_org_not_allowed"} plus a result entry with api_error_status 403. A usage-limited run carries 429 and a rejected rate_limit_event, and a real review carries is_error false with no status, so the 401/403 test fires on the refused credential alone. * fix(ci): stop a refused credential reddening the issue analysis The same exit-0 refusal reaches this workflow's "posted no reply" check, which fails for the same reason and shows up as seven failed runs in a day. It never attaches to a pull request -- the trigger excludes them -- so this is the same step and the same 401/403 transcript test applied where the refusal lands. Reported only as a warning annotation: nothing was analysed, and there is no comment worth posting about a credential the maintainer has to renew.
  • f8db7f6c29 fix(nodes): say which half of node mTLS failed, and say it as an error (#6565) * fix(nodes): say which half of node mTLS failed, and say it as an error A configured client CA bundle that will not parse produced the same warning as a settings read that failed, and both read as though mTLS were merely unavailable. It is not: the node API silently stops accepting client certificates, callers fall back to a bearer token or lose their only credential, and the one line saying so is a warning at boot. Report it at error level, and distinguish the two causes rather than attributing a storage fault to the operator's certificate bundle. NodeMtlsClientCAPool now tags the parse failure with ErrNodeMtlsTrustBundleInvalid; its message text is unchanged, so anything matching on the existing string still matches. Startup is deliberately left alone. Refusing to boot was considered and rejected: the bundle is one of two equal credentials here, a panel that will not start takes the proxies and the subscription server with it, and bundles written before the stricter validation landed in #6188 are already stored, editable only through the panel that would no longer come up. The tests pin the tag on an unusable bundle and its absence on an unset one; without the tag the first goes red. * test(nodes): drop a duplicate node mTLS trust-bundle test TestNodeMtlsClientCAPoolLeavesUnsetBundleUntagged asserted only that an unset nodeMtlsClientCAPem yields (nil, nil). That path returns before the line the sentinel change touched, so the test was green with and without ErrNodeMtlsTrustBundleInvalid, and TestNodeMtlsClientCAPool already pins the same two assertions on the same fixture. A test that passes either way certifies nothing and then gets cited as coverage for the sentinel. TestNodeMtlsClientCAPoolTagsAnInvalidBundle, which does go red without the sentinel, stays as the regression guard. --------- Co-authored-by: Sanaei <[email protected]>
  • 536f9a6338 fix(tgbot): localize QR caption via I18nBot (#6564) * fix(panel): accept 2FA codes from adjacent TOTP windows CheckUser compared only gotp.Now(), so a code submitted at the end of its 30s window (or with slight client/server clock drift) failed with 'invalid 2fa code', while the immediate retry in the next window succeeded. Accept current +/-1 window, the standard TOTP skew tolerance. Fixes MHSanaei/3x-ui#6535 * fix(panel): share TOTP skew tolerance with VerifyTwoFactorCode Move the +/-1 window helper to internal/util/totp so both 2FA acceptance points use it: login (CheckUser) and disable/rebind plus username/password changes (VerifyTwoFactorCode). Also shrink comments to the 2-line house rule and anchor the unit test mid-window to avoid a step-boundary flake. Addresses review on #6546 (MEDIUM + 2 LOWs). * fix(tgbot): localize QR caption via I18nBot sendClientQRLinks hardcoded English 'QRCode for client <email>:', bypassing I18nBot, so non-English bot languages (e.g. ru-RU) still got English. Add tgbot.answers.qrCodeForClient key with Email param in all 13 locales and route the caption through I18nBot. Fixes MHSanaei/3x-ui#6562 * fix(tgbot): repair locale JSON syntax, harden QR i18n test - Add missing separators so all 13 locale files parse again. - Rewrite the regression test to read the real shipped files (fails on malformed JSON or missing key). - Add TestTgbotLocalesQrKeyValid covering every locale file. * chore(tgbot): drop QR caption tests that cannot catch the bug TestQRCodeForClientLocalizes never calls sendClientQRLinks: it registers two messages in a synthetic bundle and asserts on I18nBot, a passthrough to go-i18n. With the tgbot_client.go line reverted to the hardcoded English caption, both it and TestTgbotLocalesQrKeyValid still pass, so neither certifies the fix. The malformed-locale class they were added for is already pinned twice: the discord package's TestMain loads every translation file through locale.InitLocalizer and panics on invalid JSON, and frontend/src/test/i18n-dead-keys.test.ts parses all 13 locales and checks each carries the en-US key set. Both go red on the #6564 syntax error this PR first shipped. --------- Co-authored-by: sdhfsl <[email protected]> Co-authored-by: Sanaei <[email protected]>
  • View comparison for these 10 commits »

3 hours ago

txlyre synced new reference dependabot/go_modules/github.com/gin-contrib/sessions-1.1.2 to txlyre/3x-ui from mirror

3 hours ago

txlyre pushed to master at txlyre/jk

3 days ago

txlyre pushed to master at txlyre/jk

3 days ago