fix(e2e): add missing i18n translations for encryption key decode errors#39914
fix(e2e): add missing i18n translations for encryption key decode errors#39914thekishandev wants to merge 3 commits into
Conversation
|
Looks like this PR is not ready to merge, because of the following issues:
Please fix the issues and try again If you have any trouble, please check the PR guidelines |
|
WalkthroughThis PR adds Linux architecture support configuration to Yarn, introduces two new English translation keys for E2EE password/key decoding failures, and updates the E2EE client error messaging to use i18n translations instead of hardcoded English strings. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR aims to complete i18n coverage for E2E encryption key decode error banners by replacing hardcoded English strings in the Meteor client with translation keys.
Changes:
- Added two E2E-related English translation entries to
en.i18n.json. - Replaced hardcoded banner
title/htmlstrings witht()lookups in the E2E client error handler. - Updated Yarn configuration by introducing a
supportedArchitecturesrestriction.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| packages/i18n/src/locales/en.i18n.json | Adds new English translation keys for E2E decode/password error messaging. |
| apps/meteor/client/lib/e2ee/rocketchat.e2e.ts | Uses the new translation keys in the E2E banner shown when private key decoding fails. |
| .yarnrc.yml | Introduces supportedArchitectures configuration restricting installs to Linux. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| supportedArchitectures: | ||
| os: linux | ||
|
|
There was a problem hiding this comment.
The new supportedArchitectures setting restricts installs to Linux only. This is unrelated to the PR’s stated i18n goal and can break yarn install for contributors/CI running on macOS/Windows. Consider removing this from the PR (or expanding it to all intended OSes using Yarn’s expected list format, e.g. os: [linux, darwin, win32], in a separate, clearly-scoped change).
| supportedArchitectures: | |
| os: linux |
| title: () => t('E2E_key_decode_failed'), | ||
| html: () => t('E2E_password_wrong_click_to_retry'), |
There was a problem hiding this comment.
PR description mentions adding a key named E2E_password_seems_wrong_click_to_retry, but the code uses E2E_password_wrong_click_to_retry. Please align the PR description (or the key name) to avoid confusion for reviewers and future searchability.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.yarnrc.yml:
- Around line 15-16: The supportedArchitectures block in .yarnrc.yml is invalid
because os is a scalar; change supportedArchitectures to use arrays and add cpu
and libc at the same level as os. Specifically, replace "supportedArchitectures:
os: linux" with a block like supportedArchitectures: os: [linux] cpu:
[<appropriate-cpu-archs>] libc: [<appropriate-libcs>] (populate the cpu and libc
arrays with your project's supported entries) so the schema expects arrays for
os/cpu/libc and the config no longer fails Yarn 4.12.0 validation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f000053c-704e-46b4-bd73-b542a42d5693
📒 Files selected for processing (3)
.yarnrc.ymlapps/meteor/client/lib/e2ee/rocketchat.e2e.tspackages/i18n/src/locales/en.i18n.json
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: cubic · AI code reviewer
- GitHub Check: Agent
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
**/*.{ts,tsx,js}: Write concise, technical TypeScript/JavaScript with accurate typing in Playwright tests
Avoid code comments in the implementation
Files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.ts
🧠 Learnings (15)
📓 Common learnings
Learnt from: d-gubert
Repo: RocketChat/Rocket.Chat PR: 37547
File: packages/i18n/src/locales/en.i18n.json:634-634
Timestamp: 2025-11-19T12:32:29.696Z
Learning: Repo: RocketChat/Rocket.Chat
Context: i18n workflow
Learning: In this repository, new translation keys should be added to packages/i18n/src/locales/en.i18n.json only; other locale files are populated via the external translation pipeline and/or fall back to English. Do not request adding the same key to all locale files in future reviews.
Learnt from: smirk-dev
Repo: RocketChat/Rocket.Chat PR: 39625
File: apps/meteor/app/api/server/v1/push.ts:85-97
Timestamp: 2026-03-14T14:58:58.834Z
Learning: In RocketChat/Rocket.Chat, the `push.token` POST/DELETE endpoints in `apps/meteor/app/api/server/v1/push.ts` were already migrated to the chained router API pattern on `develop` prior to PR `#39625`. `cleanTokenResult` (which strips `authToken` and returns `PushTokenResult`) and `isPushTokenPOSTProps`/`isPushTokenDELETEProps` validators already exist on `develop`. PR `#39625` only migrates `push.get` and `push.info` to the chained pattern. Do not flag `cleanTokenResult` or `PushTokenResult` as newly introduced behavior-breaking changes when reviewing this PR.
Learnt from: dougfabris
Repo: RocketChat/Rocket.Chat PR: 39425
File: apps/meteor/client/lib/chats/flows/uploadFiles.ts:28-33
Timestamp: 2026-03-12T17:12:49.121Z
Learning: Rocket.Chat — apps/meteor/client/lib/chats/flows/uploadFiles.ts: When E2E_Enable_Encrypt_Files is disabled, plaintext file uploads are allowed in E2E rooms; this fallback is expected and should not be flagged as a security regression.
📚 Learning: 2026-03-23T19:33:43.067Z
Learnt from: cardoso
Repo: RocketChat/Rocket.Chat PR: 39818
File: apps/meteor/client/hooks/usePruneWarningMessage.ts:45-56
Timestamp: 2026-03-23T19:33:43.067Z
Learning: In Rocket.Chat, cron expressions used for the retention policy (e.g., `RetentionPolicy_Advanced_Precision_Cron`) follow the `cron` npm package convention, which uses **0-indexed months** (0 = January, 11 = December) rather than POSIX-style 1–12. In `apps/meteor/client/hooks/usePruneWarningMessage.ts`, the local `sendAt` logic intentionally mirrors this behavior—do **not** adjust `date.getMonth()` with `+1` or similar changes, because it will break tests and introduce inconsistency with the backend.
Applied to files:
.yarnrc.yml
📚 Learning: 2026-03-12T17:12:49.121Z
Learnt from: dougfabris
Repo: RocketChat/Rocket.Chat PR: 39425
File: apps/meteor/client/lib/chats/flows/uploadFiles.ts:28-33
Timestamp: 2026-03-12T17:12:49.121Z
Learning: Rocket.Chat — apps/meteor/client/lib/chats/flows/uploadFiles.ts: When E2E_Enable_Encrypt_Files is disabled, plaintext file uploads are allowed in E2E rooms; this fallback is expected and should not be flagged as a security regression.
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.tspackages/i18n/src/locales/en.i18n.json
📚 Learning: 2025-10-07T15:08:37.419Z
Learnt from: cardoso
Repo: RocketChat/Rocket.Chat PR: 36942
File: apps/meteor/client/lib/e2ee/pbkdf2.ts:13-45
Timestamp: 2025-10-07T15:08:37.419Z
Learning: In apps/meteor/client/lib/e2ee/pbkdf2.ts, the team has decided to use Latin-1 encoding (via Binary.toArrayBuffer and Binary.toString) for password encoding and decrypt output instead of UTF-8 encoding. This is a deliberate choice for E2EE password/key material handling.
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.tspackages/i18n/src/locales/en.i18n.json
📚 Learning: 2025-11-19T12:32:29.696Z
Learnt from: d-gubert
Repo: RocketChat/Rocket.Chat PR: 37547
File: packages/i18n/src/locales/en.i18n.json:634-634
Timestamp: 2025-11-19T12:32:29.696Z
Learning: Repo: RocketChat/Rocket.Chat
Context: i18n workflow
Learning: In this repository, new translation keys should be added to packages/i18n/src/locales/en.i18n.json only; other locale files are populated via the external translation pipeline and/or fall back to English. Do not request adding the same key to all locale files in future reviews.
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.tspackages/i18n/src/locales/en.i18n.json
📚 Learning: 2025-11-19T18:20:07.720Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 37419
File: packages/i18n/src/locales/en.i18n.json:918-921
Timestamp: 2025-11-19T18:20:07.720Z
Learning: Repo: RocketChat/Rocket.Chat — i18n/formatting
Learning: This repository uses a custom message formatting parser in UI blocks/messages; do not assume standard Markdown rules. For keys like Call_ended_bold, Call_not_answered_bold, Call_failed_bold, and Call_transferred_bold in packages/i18n/src/locales/en.i18n.json, retain the existing single-asterisk emphasis unless maintainers request otherwise.
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.ts
📚 Learning: 2026-02-12T15:39:28.416Z
Learnt from: dougfabris
Repo: RocketChat/Rocket.Chat PR: 32703
File: apps/meteor/client/lib/chats/flows/uploadFiles.ts:52-58
Timestamp: 2026-02-12T15:39:28.416Z
Learning: In `apps/meteor/client/lib/chats/flows/uploadFiles.ts`, when E2E encryption is required but not allowed (e.g., `E2E_Enable_Encrypt_Files` setting is disabled), the function intentionally abandons the entire upload queue and displays a toast error. This fail-fast behavior prevents partial uploads when encryption requirements cannot be met and is the expected behavior, not a bug.
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.ts
📚 Learning: 2026-02-24T19:36:55.089Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 38493
File: apps/meteor/tests/e2e/page-objects/fragments/home-content.ts:60-82
Timestamp: 2026-02-24T19:36:55.089Z
Learning: In RocketChat/Rocket.Chat e2e tests (apps/meteor/tests/e2e/page-objects/fragments/home-content.ts), thread message preview listitems do not have aria-roledescription="message", so lastThreadMessagePreview locator cannot be scoped to messageListItems (which filters for aria-roledescription="message"). It should remain scoped to page.getByRole('listitem') or mainMessageList.getByRole('listitem').
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.ts
📚 Learning: 2025-11-17T22:38:48.631Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 37505
File: packages/i18n/src/locales/en.i18n.json:3765-3765
Timestamp: 2025-11-17T22:38:48.631Z
Learning: Rocket.Chat i18n copy: Keep sentence case for the value of "Notification_Desktop_show_voice_calls" in packages/i18n/src/locales/en.i18n.json (“Show desktop notifications for voice calls”) per design directive; do not change to Title Case even if nearby labels differ.
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.ts
📚 Learning: 2026-03-14T14:58:58.834Z
Learnt from: smirk-dev
Repo: RocketChat/Rocket.Chat PR: 39625
File: apps/meteor/app/api/server/v1/push.ts:85-97
Timestamp: 2026-03-14T14:58:58.834Z
Learning: In RocketChat/Rocket.Chat, the `push.token` POST/DELETE endpoints in `apps/meteor/app/api/server/v1/push.ts` were already migrated to the chained router API pattern on `develop` prior to PR `#39625`. `cleanTokenResult` (which strips `authToken` and returns `PushTokenResult`) and `isPushTokenPOSTProps`/`isPushTokenDELETEProps` validators already exist on `develop`. PR `#39625` only migrates `push.get` and `push.info` to the chained pattern. Do not flag `cleanTokenResult` or `PushTokenResult` as newly introduced behavior-breaking changes when reviewing this PR.
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.ts
📚 Learning: 2026-02-24T19:22:52.984Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 38493
File: apps/meteor/tests/e2e/omnichannel/omnichannel-send-pdf-transcript.spec.ts:66-67
Timestamp: 2026-02-24T19:22:52.984Z
Learning: In RocketChat/Rocket.Chat Playwright e2e tests, prefer using translated text and ARIA roles (getByRole, getByText, etc.) over data-qa locators. If translation values change, update the corresponding test locators accordingly. Never prefer data-qa locators.
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.ts
📚 Learning: 2025-10-16T21:09:51.816Z
Learnt from: cardoso
Repo: RocketChat/Rocket.Chat PR: 36942
File: apps/meteor/client/lib/e2ee/keychain.ts:148-156
Timestamp: 2025-10-16T21:09:51.816Z
Learning: In the RocketChat/Rocket.Chat repository, only platforms with native crypto.randomUUID() support are targeted, so fallback implementations for crypto.randomUUID() are not required in E2EE or cryptographic code.
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.ts
📚 Learning: 2026-02-10T16:32:42.586Z
Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 38528
File: apps/meteor/client/startup/roles.ts:14-14
Timestamp: 2026-02-10T16:32:42.586Z
Learning: In Rocket.Chat's Meteor client code, DDP streams use EJSON and Date fields arrive as Date objects; do not manually construct new Date() in stream handlers (for example, in sdk.stream()). Only REST API responses return plain JSON where dates are strings, so implement explicit conversion there if needed. Apply this guidance to all TypeScript files under apps/meteor/client to ensure consistent date handling in DDP streams and REST responses.
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In the Rocket.Chat repository, do not reference Biome lint rules in code review feedback. Biome is not used even if biome.json exists; only reference Biome rules if there is explicit, project-wide usage documented. For TypeScript files, review lint implications without Biome guidance unless the project enables Biome rules.
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In this repository (RocketChat/Rocket.Chat), Biome lint rules are not used even if a biome.json exists. When reviewing TypeScript files (e.g., packages/ui-voip/src/providers/useMediaSession.ts), ensure lint suggestions do not reference Biome-specific rules. Rely on general ESLint/TypeScript lint rules and project conventions instead.
Applied to files:
apps/meteor/client/lib/e2ee/rocketchat.e2e.ts
🔇 Additional comments (2)
packages/i18n/src/locales/en.i18n.json (1)
1894-1895: The new E2EE translation keys are correctly matched between the locale file and their call sites. No action needed.The shell verification confirms that
apps/meteor/client/lib/e2ee/rocketchat.e2e.tsreferences both keys exactly as they appear inpackages/i18n/src/locales/en.i18n.json:
- Line 378 calls
t('E2E_key_decode_failed')- Line 379 calls
t('E2E_password_wrong_click_to_retry')The keys are consistent, and the translation strings are properly localized to only the English locale file per repository convention.
> Likely an incorrect or invalid review comment.apps/meteor/client/lib/e2ee/rocketchat.e2e.ts (1)
378-379: No action required. The i18n keyE2E_password_wrong_click_to_retryis correctly defined inpackages/i18n/src/locales/en.i18n.jsonand correctly used on line 379.> Likely an incorrect or invalid review comment.
| supportedArchitectures: | ||
| os: linux |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify whether any workflow/job performs Yarn installs without the setup-node override.
# Expected: every install path should either use .github/actions/setup-node or set supportedArchitectures with os+cpu+libc.
set -euo pipefail
echo "== Workflows invoking setup-node action =="
rg -n --iglob '*.yml' -C2 '\.\/\.github\/actions\/setup-node|uses:\s*\.\/\.github\/actions\/setup-node' .github/workflows || true
echo
echo "== Workflows running yarn install/focus directly =="
rg -n --iglob '*.yml' -C2 'run:\s*.*\byarn\b.*(install|workspaces focus|--immutable|^\s*yarn\s*$)' .github/workflows || true
echo
echo "== Current project-level Yarn supportedArchitectures block =="
rg -n -C3 'supportedArchitectures|cpu:|os:|libc:' .yarnrc.yml || trueRepository: RocketChat/Rocket.Chat
Length of output: 654
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Check for setup-node action file =="
fd -t f "setup-node" .github/actions/ 2>/dev/null | head -20
echo
echo "== Check ci.yml for setup-node and yarn patterns =="
if [ -f ".github/workflows/ci.yml" ]; then
echo "File exists. Checking setup-node usage:"
grep -n "setup-node\|yarn.*install\|yarn.*workspaces" .github/workflows/ci.yml | head -30
else
echo "ci.yml not found"
fi
echo
echo "== List all workflow files =="
fd -t f "\.yml$|\.yaml$" .github/workflows/ 2>/dev/null | head -20
echo
echo "== Search for any yarn install commands in workflows =="
rg -n "yarn" .github/workflows/ --max-count=50 2>/dev/null || echo "No matches found"
echo
echo "== Check if os: linux is valid YAML and what the format means =="
echo "Examining .yarnrc.yml structure:"
head -20 .yarnrc.ymlRepository: RocketChat/Rocket.Chat
Length of output: 3580
🌐 Web query:
Yarn 4.12.0 supportedArchitectures configuration schema format os cpu libc
💡 Result:
The supportedArchitectures configuration in Yarn (Berry, including version 4.12.0) is defined in the .yarnrc.yml file. It controls which OS, CPU architectures, and libc variants Yarn will install packages for, particularly useful for multi-platform setups like zero-installs or Docker/CI where you need binaries for multiple targets. Schema format (YAML): supportedArchitectures: os: ["current", "darwin", "linux", "win32"] # process.platform values; "current" includes host OS cpu: ["current", "x64", "arm64", "ia32"] # process.arch values; "current" includes host CPU libc: ["current", "glibc", "musl"] # C library variants; "current" includes host libc (Node 14+) - All three keys (os, cpu, libc) are optional arrays of strings. - Use "current" to always include the host platform. - To support multiple platforms (e.g., for SWC/esbuild binaries), specify all relevant values explicitly, as packages like @swc/core-linux-x64-gnu require matching os:linux, cpu:x64, libc:glibc. - Default behavior (unset): Only installs packages matching the current host (os/cpu/libc). - In Yarn 4.x, configuration merging may add extra architectures automatically in some cases (e.g., glibc deps). This works in Yarn 4.12.0, as confirmed by recent issues (Dec 2025). For package.json manifests, similar os, cpu, libc fields filter binaries at install time.
Citations:
- 1: `supportedArchitectures` setting yarnpkg/berry#3855
- 2: http://v3.yarnpkg.com/configuration/yarnrc
- 3: https://v3.yarnpkg.com/configuration/yarnrc/
- 4: [Bug?]: supported architectures behaviour doesn't support zero installs yarnpkg/berry#4615
- 5: [Bug?]: v4 configuration merging works unexpectedly for
supportedArchitecturesyarnpkg/berry#6067 - 6: [Bug] Not all linkers respect
supportedArchitecturesyarnpkg/berry#4323 - 7: Adds support for the libc field in package.json yarnpkg/berry#3981
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Search for setup-node action.yml anywhere in repo =="
fd -t f "action.yml" .github/ 2>/dev/null | xargs -I {} sh -c 'echo "File: {}"; head -5 {}'
echo
echo "== Context around setup-node usage in ci.yml (line 193) =="
sed -n '185,210p' .github/workflows/ci.yml
echo
echo "== Context around setup-node usage in ci.yml (line 622) =="
sed -n '615,645p' .github/workflows/ci.yml
echo
echo "== Search for yarn install in ci.yml and preceding steps =="
grep -n -B10 "yarn.*install\|yarn\s*$\|yarn workspaces" .github/workflows/ci.yml | head -40
echo
echo "== Check if there are jobs that run yarn without preceding setup-node =="
# Find all yarn commands and check if they have setup-node before them
rg -n "run:.*yarn" .github/workflows/ci.yml -A1 -B1 | head -60Repository: RocketChat/Rocket.Chat
Length of output: 3319
🌐 Web query:
Yarn 4.12.0 supportedArchitectures os as scalar string invalid schema error
💡 Result:
The error "supportedArchitectures os as scalar string invalid schema error" in Yarn 4.12.0 occurs when the os field under supportedArchitectures in .yarnrc.yml is configured as a scalar string instead of an array of strings, violating the JSON schema validation enforced by Yarn. According to official Yarn documentation, supportedArchitectures.os must be an array: supportedArchitectures: os: - current - darwin - linux - win32 Incorrect example causing the error: supportedArchitectures: os: linux # scalar string - invalid Correct example: supportedArchitectures: os: [linux, darwin] # array - valid Yarn 4.12.0 includes a "Fix JSON Schema" change (PR #6973), likely tightening schema validation, which triggers this error for non-compliant configurations. Use YAML array syntax (- item or [item1, item2]) for os, cpu, and libc fields. No specific issues found for exactly 4.12.0 beyond general supportedArchitectures bugs in v4 (e.g., merging, negated checks), but schema strictness explains the "scalar string invalid schema" message.
Citations:
- 1: [Bug?]: supported architectures behaviour doesn't support zero installs yarnpkg/berry#4615
- 2: [Bug?]: v4 configuration merging works unexpectedly for
supportedArchitecturesyarnpkg/berry#6067 - 3: `supportedArchitectures` setting yarnpkg/berry#3855
- 4: [Bug?]: json-schema yarnrc unsafeHttpWhitelist yarnpkg/berry#5023
- 5: https://yarnpkg.com/configuration/yarnrc
- 6: https://yarnpkg.com/configuration/yarnrc/
- 7: http://v2.yarnpkg.com/configuration
- 8: docs: revamp configuration doc generation based on json schemas yarnpkg/berry#1964
- 9: docs: generate config from json schema yarnpkg/berry#1008
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Full setup-node/action.yml file =="
cat .github/actions/setup-node/action.yml
echo
echo "== Check if there are runs steps or shell scripts =="
fd -t f "setup-node" .github/actions/setup-node/ 2>/dev/null
echo
echo "== List all files in setup-node action directory =="
ls -la .github/actions/setup-node/Repository: RocketChat/Rocket.Chat
Length of output: 3905
🌐 Web query:
Yarn 4.12.0 scalar vs array supportedArchitectures validation error failing install
💡 Result:
The error "scalar vs array supportedArchitectures validation error failing install" in Yarn 4.12.0 likely occurs due to incorrect configuration of the supportedArchitectures setting in .yarnrc.yml. This setting must be an object containing arrays for os, cpu, and/or libc, not a scalar value or improperly structured array. Correct format from official docs and issues: supportedArchitectures: os: [darwin, linux] cpu: [x64, arm64] libc: [glibc, musl] Common mistakes causing validation errors: - Using a scalar string instead of arrays (e.g., os: linux instead of os: [linux]). - Top-level array (e.g., supportedArchitectures: [linux]). - Missing array brackets or YAML indentation issues. Yarn 4.12.0 includes a JSON Schema fix (PR #6973), which enforces stricter validation on config files like .yarnrc.yml and package.json, catching such schema violations during install/post-resolution validation (YN0001 errors). To fix: 1. Check .yarnrc.yml for proper YAML structure matching the schema. 2. Use yarn config set supportedArchitectures.os "['darwin','linux']" or edit manually. 3. Run yarn install again. If in package.json (manifest fields os/cpu/libc), ensure they are arrays, not scalars. No specific bug reports match exactly, but config merging and schema strictness issues (#6067, #6973) align. Downgrade to Yarn 4.11 if urgent, but fix config for 4.12.0.
Citations:
- 1: [Bug?]: supported architectures behaviour doesn't support zero installs yarnpkg/berry#4615
- 2: https://yarnpkg.com/advanced/error-codes
- 3: [Bug?]: v4 configuration merging works unexpectedly for
supportedArchitecturesyarnpkg/berry#6067 - 4: `supportedArchitectures` setting yarnpkg/berry#3855
- 5: https://yarnpkg.com/configuration/manifest
- 6: [Feature] More controlled architecture matrix yarnpkg/berry#4604
- 7: docs: revamp configuration doc generation based on json schemas yarnpkg/berry#1964
- 8: https://nodejs.libhunt.com/berry-changelog/4.12.0
Fix supportedArchitectures schema: os must be an array, and include cpu/libc at the base configuration level.
Line 16 uses a scalar (os: linux), which violates Yarn 4.12.0's JSON schema. The setup-node action temporarily corrects this via yarn config set during CI runs, then restores the broken .yarnrc.yml. Any yarn command outside that context—including local development—will fail schema validation. Move the full architecture specification into .yarnrc.yml permanently.
Recommended fix
supportedArchitectures:
- os: linux
+ os:
+ - linux
+ cpu:
+ - x64
+ - arm64
+ libc:
+ - glibc
+ - musl📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| supportedArchitectures: | |
| os: linux | |
| supportedArchitectures: | |
| os: | |
| - linux | |
| cpu: | |
| - x64 | |
| - arm64 | |
| libc: | |
| - glibc | |
| - musl |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.yarnrc.yml around lines 15 - 16, The supportedArchitectures block in
.yarnrc.yml is invalid because os is a scalar; change supportedArchitectures to
use arrays and add cpu and libc at the same level as os. Specifically, replace
"supportedArchitectures: os: linux" with a block like supportedArchitectures:
os: [linux] cpu: [<appropriate-cpu-archs>] libc: [<appropriate-libcs>] (populate
the cpu and libc arrays with your project's supported entries) so the schema
expects arrays for os/cpu/libc and the config no longer fails Yarn 4.12.0
validation.
i18n: add missing translations for E2E encryption errors
Proposed changes (including videos or screenshots)
This PR addresses technical debt by extracting two hardcoded English strings from the E2E encryption error handler in
rocketchat.e2e.tsthat were marked with// TODO: missing translation.Changes made:
E2E_key_decode_failedandE2E_password_seems_wrong_click_to_retrytoen.i18n.json.t()translation function calls.TODOcomments.This introduces zero runtime behavioral changes and makes the E2E encryption errors fully translatable.
Issue(s)
Steps to test or reproduce
Further comments
This is a small, low-risk cleanup targeted at improving i18n coverage in the E2E module.