feat: Console SDK update for version 3.2.0#63
Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ⛔ Files ignored due to path filters (6)
📒 Files selected for processing (112)
WalkthroughBumps package version and SDK metadata from 3.1.0 to 3.2.0 (package.json, README.md, src/client.ts). Large additions and reorganization in CHANGELOG.md including many new release sections (22.3.1, 22.1.0 … 17.0.0) and a duplicated 22.3.1 block. Adds Deno runtimes (deno-1.21, deno-1.24, deno-1.35) to runtime-related enums (src/enums/build-runtime.ts, runtime.ts, runtimes.ts). Extends Resources enum with team/membership/function/deployment/environment-variable/site/site-deployment/site-variable. Updates Scopes with account, teams.read/write and multiple platforms/projects/keys/devKeys/webhooks read/write entries. Reorders TemplateReferenceType.Branch and modifies UseCases members. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
premtsd-code
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
src/enums/use-cases.ts (1)
7-7:Devtoolskey is not proper PascalCase — considerDevTools.All other multi-word keys in this enum are PascalCase.
Devtoolsconflates two words without capitalising the second one.Since this is auto-generated code, the fix should be applied in the SDK generator template.
♻️ Proposed rename
- Devtools = 'dev-tools', + DevTools = 'dev-tools',🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/enums/use-cases.ts` at line 7, The enum member name Devtools in the use-cases enum should be renamed to DevTools to match PascalCase convention and other multi-word keys; update the generated enum item in the SDK generator template so the enum symbol UseCases (or file src/enums/use-cases.ts) emits DevTools = 'dev-tools' instead of Devtools, and regenerate the code so all references (imports/usages of UseCases.Devtools) are updated to UseCases.DevTools across the codebase.src/enums/resources.ts (1)
17-20: Three new keys deviate from PascalCase — update generator template.
Environmentvariable,Sitedeployment, andSitevariableshould beEnvironmentVariable,SiteDeployment, andSiteVariableto match the existing PascalCase convention of every other key in this enum. Because this is auto-generated code, the fix belongs in the SDK generator.♻️ Proposed rename
- Environmentvariable = 'environment-variable', + EnvironmentVariable = 'environment-variable', Site = 'site', - Sitedeployment = 'site-deployment', - Sitevariable = 'site-variable', + SiteDeployment = 'site-deployment', + SiteVariable = 'site-variable',🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/enums/resources.ts` around lines 17 - 20, The enum entries Environmentvariable, Sitedeployment, and Sitevariable are incorrectly cased and should be PascalCase to match the rest of the enum (use EnvironmentVariable, SiteDeployment, SiteVariable); update the SDK generator template that emits the Resources enum so it transforms resource names to PascalCase when producing enum keys (adjust the naming helper used when generating symbols for Environmentvariable/Sitedeployment/Sitevariable to produce EnvironmentVariable/SiteDeployment/SiteVariable and regenerate the enum output).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@CHANGELOG.md`:
- Line 117: Update the two prose phrases identified: change the phrase "markdown
code fences" to "Markdown code fences" (capitalize Markdown) and change "multi
region endpoints" to "multi-region endpoints" (add hyphen), locating these exact
strings in CHANGELOG.md to replace them.
- Around line 104-190: The changelog contains likely cross-SDK historical
entries (heads like "## 22.3.1", "## 22.1.0", "## 22.0.0") that duplicate or
overlap with existing 2.x entries and create a version gap; verify whether the
sections under headings "## 22.3.1" through "## 17.0.0" belong to this SDK, and
if they do not, remove them, otherwise add a clear marker above that block
(e.g., "## Historical versions (pre-1.x renumber)") with a short explanation of
the renumbering to prevent confusion; update or remove the duplicated content
under "## 22.1.0" and "## 22.0.0" to avoid repeating the existing "## 2.3.0"/"##
2.2.0" entries.
In `@src/enums/scopes.ts`:
- Around line 75-76: Remove the DevKeysRead and DevKeysWrite entries from the
Scopes enum: locate the Scopes enum declaration (symbols: Scopes, DevKeysRead,
DevKeysWrite) and delete those two enum members, then search the codebase for
any references to DevKeysRead or DevKeysWrite and replace or remove them (they
should not be used as API key scopes); ensure no tests or serialization code
expect these values and update affected tests or documentation accordingly.
---
Nitpick comments:
In `@src/enums/resources.ts`:
- Around line 17-20: The enum entries Environmentvariable, Sitedeployment, and
Sitevariable are incorrectly cased and should be PascalCase to match the rest of
the enum (use EnvironmentVariable, SiteDeployment, SiteVariable); update the SDK
generator template that emits the Resources enum so it transforms resource names
to PascalCase when producing enum keys (adjust the naming helper used when
generating symbols for Environmentvariable/Sitedeployment/Sitevariable to
produce EnvironmentVariable/SiteDeployment/SiteVariable and regenerate the enum
output).
In `@src/enums/use-cases.ts`:
- Line 7: The enum member name Devtools in the use-cases enum should be renamed
to DevTools to match PascalCase convention and other multi-word keys; update the
generated enum item in the SDK generator template so the enum symbol UseCases
(or file src/enums/use-cases.ts) emits DevTools = 'dev-tools' instead of
Devtools, and regenerate the code so all references (imports/usages of
UseCases.Devtools) are updated to UseCases.DevTools across the codebase.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
CHANGELOG.mdREADME.mdpackage.jsonsrc/client.tssrc/enums/build-runtime.tssrc/enums/resources.tssrc/enums/runtime.tssrc/enums/runtimes.tssrc/enums/scopes.tssrc/enums/template-reference-type.tssrc/enums/use-cases.ts
CHANGELOG.md
Outdated
| * Fix `Roles` enum removed from Teams service; `roles` parameter now accepts `string[]` | ||
| * Fix parameter detection in overloaded methods to check for optional params (Account, Avatars, Graphql) | ||
| * Fix WebSocket connection handling with stale connection guards and improved close/reconnect logic | ||
| * Fix doc examples wrapped in markdown code fences |
There was a problem hiding this comment.
Capitalise "Markdown" and hyphenate "multi-region" (lines 117 and 170).
Two minor prose issues flagged by static analysis:
- Line 117: "markdown code fences" → "Markdown code fences" (proper noun).
- Line 170: "multi region endpoints" → "multi-region endpoints" (compound adjective).
🧰 Tools
🪛 LanguageTool
[uncategorized] ~117-~117: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ...ect logic * Fix doc examples wrapped in markdown code fences ## 22.0.0 * Add array-bas...
(MARKDOWN_NNP)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@CHANGELOG.md` at line 117, Update the two prose phrases identified: change
the phrase "markdown code fences" to "Markdown code fences" (capitalize
Markdown) and change "multi region endpoints" to "multi-region endpoints" (add
hyphen), locating these exact strings in CHANGELOG.md to replace them.
| DevKeysRead = 'devKeys.read', | ||
| DevKeysWrite = 'devKeys.write', |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the scopes.ts file to see all scope definitions
cat -n src/enums/scopes.tsRepository: appwrite/sdk-for-console
Length of output: 3368
🏁 Script executed:
# Search for any Appwrite documentation or references about devKeys scope casing
rg "devkeys|devKeys" -i --type ts --type js --type md --type jsonRepository: appwrite/sdk-for-console
Length of output: 883
🏁 Script executed:
# Look for any server-side scope definitions or documentation in the repo
fd -e md -e json | xargs grep -l "scope" | head -20Repository: appwrite/sdk-for-console
Length of output: 498
🌐 Web query:
Appwrite API devKeys scope authentication server documentation
💡 Result:
- Dev keys vs API keys (server auth): Appwrite Dev keys are not API keys and can’t be used interchangeably. API keys are the server/CLI secret used for production server-side integrations, and what they can access is controlled by scopes. Dev keys are meant for development/test client usage to help avoid abuse limits and CORS issues. [1]
- How server authentication works (REST): For server-to-server REST calls, send:
X-Appwrite-Project: <PROJECT_ID>X-Appwrite-Key: <API_KEY>(the server API key; keep it secret)
Appwrite treats this as a server integration authenticated by the key’s scopes. [2]
- Scopes (what to grant): When creating an API key in the Console, you choose scopes (e.g.,
users.read,databases.write, etc.). Best practice is to grant only the minimum scopes needed. [1] - Functions (“dynamic API key”): Inside Appwrite Functions, Appwrite provides a dynamic API key per execution (
APPWRITE_FUNCTION_API_KEYenv var andx-appwrite-keyheader). You configure its scopes in the Function’s Settings → Scopes. [3] - Client vs server behavior: Client APIs depend on user sessions/permissions, while server APIs depend on the API key scopes (and ignore user permissions). [4]
Sources: [1] API keys (incl. Dev keys + scopes) — Appwrite Docs (appwrite.io), [2] REST API headers/auth — Appwrite Docs (appwrite.io), [3] Functions dynamic API key + scopes — Appwrite Docs (appwrite.io), [4] Client vs Server APIs — Appwrite Docs (appwrite.io)
Citations:
- 1: https://appwrite.io/docs/advanced/platform/api-keys?utm_source=openai
- 2: https://appwrite.io/docs/apis/rest?utm_source=openai
- 3: https://appwrite.io/docs/products/functions/develop?utm_source=openai
- 4: https://appwrite.io/docs/references?utm_source=openai
🏁 Script executed:
# Search for any test files or API documentation that might show scope values
rg "devKeys\.read|devkeys\.read" -iRepository: appwrite/sdk-for-console
Length of output: 121
🏁 Script executed:
# Look for any API endpoint definitions or scope validation
rg "scope" -A 5 -B 5 src/services/projects.ts | head -100Repository: appwrite/sdk-for-console
Length of output: 4955
🌐 Web query:
Appwrite server API scope list devkeys.read exact format
💡 Result:
devkeys.read is not an Appwrite Server API key scope (it doesn’t exist in Appwrite’s official API key scope list). Appwrite Dev keys are a separate concept from API keys and aren’t controlled via Server API key scopes. [1][2]
Appwrite Server API key scopes are lowercase strings in the format:
resource.read/resource.write(for example:users.read,databases.write,health.read,tokens.read, etc.) [1]
Source for the official scope list: the “API keys → Scopes” table in Appwrite docs. [1]
Sources:
[1] API keys (scopes list) — Appwrite Docs
[2] Dev keys — Appwrite Docs
🌐 Web query:
site:github.com appwrite/appwrite scopes devKeys
💡 Result:
GitHub repository search shows no occurrences of devKeys (or devKey / devkeys) anywhere in appwrite/appwrite:
repo:appwrite/appwrite devKeys→ 0 files found. (github.com)repo:appwrite/appwrite devKey→ 0 files found. (github.com)repo:appwrite/appwrite devkeys→ 0 files found. (github.com)
Citations:
- 1: https://github.com/appwrite/appwrite/search?q=devKeys
- 2: https://github.com/search?q=repo%3Aappwrite%2Fappwrite+devKey
- 3: https://github.com/search?q=repo%3Aappwrite%2Fappwrite+devkeys
🏁 Script executed:
# Search for any test files that might validate or reference scope values
fd -e test.ts -e test.js -e spec.ts -e spec.js | xargs rg "devKey|Scopes" 2>/dev/null | head -20Repository: appwrite/sdk-for-console
Length of output: 2395
🏁 Script executed:
# Look for any initialization or configuration files that might reference scopes
rg "scopes\|Scopes" -A 2 -B 2 src/enums/ --type tsRepository: appwrite/sdk-for-console
Length of output: 50
🏁 Script executed:
# Search for any usage of DevKeysRead or DevKeysWrite in the codebase
rg "DevKeysRead|DevKeysWrite" -r .Repository: appwrite/sdk-for-console
Length of output: 156
🌐 Web query:
Appwrite dev keys scopes authentication permissions API
💡 Result:
Appwrite: Dev Keys vs API Keys (scopes), authentication, and permissions
1) Dev Keys (development-only)
- Dev Keys are for client SDKs during local/dev to help avoid CORS issues and abuse/rate limits.
- They are not the same as API keys and can’t be used interchangeably. [1], [5]
2) API Keys (server/CLI, production) + Scopes
- API keys are secrets for Server SDKs and the Appwrite CLI (server-side / production use). [1]
- What an API key can do is controlled by scopes (not resource permissions)—grant only what you need (least privilege). [1]
- Examples of scopes include
sessions.write,users.read,users.write,teams.read,teams.write,databases.read,databases.write, etc. [1]
3) Authentication (how requests are “logged in”)
- Appwrite primarily authenticates users via sessions created with the Account API; session behavior and limits are configurable (default session limit noted in docs). [6]
- If you have your own backend and want it to act on behalf of the user, you can generate a JWT from an existing user session; the Server SDK using that JWT is limited by the user’s permissions (unlike an API key). [3]
4) Permissions (resource-level access control)
- Permissions control access to specific resources (databases/tables/rows, buckets/files, etc.) using actions like read/create/update/delete and are granted to roles (user, team, team role, any/authenticated/guest, etc.). [2]
- If you use a Server SDK with an API key + scopes, it can bypass normal resource-permission restrictions (admin/server integration behavior). [2]
5) Don’t confuse “roles”
- Appwrite has resource permission roles (used with
Role.*for data/file access) [2] and also Console/org member roles like Owner/Developer/Editor/Analyst (team collaboration inside the Console). [4]
🌐 Web query:
site:appwrite.io dev keys scopes API key
💡 Result:
-
Dev keys: For client SDKs in development/testing only. They bypass rate limits and CORS errors and can have short expirations. They are not interchangeable with API keys and must not be used in production. Created in the Console under Overview → Integrations → Dev keys. [1]
- Client requests include header:
X-Appwrite-Dev-Key: <secret>. [3]
- Client requests include header:
-
API keys: For server SDKs and the Appwrite CLI (production/server-side use). Access is controlled by scopes (grant only what you need) and keys must be kept secret (never in client apps). Created in Overview → Integrations → API keys, where you select scopes at creation time. [2]
-
Functions (dynamic API keys): Inside Appwrite Functions, a per-execution dynamic API key is provided (env
APPWRITE_FUNCTION_API_KEY, request headerx-appwrite-key). You configure its scopes in the Function’s Settings → Scopes. [4]
Sources: Appwrite Docs on Dev keys [1], API keys & scopes [2], rate-limit bypass header [3], Functions dynamic API keys/scopes [4].
Remove DevKeysRead and DevKeysWrite from Scopes enum—dev keys are not API keys and don't use scopes.
Dev keys are a separate client development feature (with X-Appwrite-Dev-Key header) and are fundamentally different from API keys. Appwrite API key scopes (like users.read, databases.write, teams.read) control server-side access—dev keys have no equivalent scope system. These enum entries don't correspond to any valid Appwrite server scope and should not be included in this enum. Using them as API key scopes would fail silently at the server with no error.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/enums/scopes.ts` around lines 75 - 76, Remove the DevKeysRead and
DevKeysWrite entries from the Scopes enum: locate the Scopes enum declaration
(symbols: Scopes, DevKeysRead, DevKeysWrite) and delete those two enum members,
then search the codebase for any references to DevKeysRead or DevKeysWrite and
replace or remove them (they should not be used as API key scopes); ensure no
tests or serialization code expect these values and update affected tests or
documentation accordingly.
There was a problem hiding this comment.
♻️ Duplicate comments (2)
CHANGELOG.md (2)
123-123:⚠️ Potential issue | 🟡 MinorTwo unresolved prose issues from the previous review.
- Line 123:
markdown code fences→Markdown code fences("Markdown" is a proper noun).- Line 176:
multi region endpoints→multi-region endpoints(compound adjective requires a hyphen).✏️ Proposed fixes
-* Fix doc examples wrapped in markdown code fences +* Fix doc examples wrapped in Markdown code fences-* Add `<REGION>` to doc examples due to the new multi region endpoints +* Add `<REGION>` to doc examples due to the new multi-region endpointsAlso applies to: 176-176
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@CHANGELOG.md` at line 123, Update the two prose issues in CHANGELOG.md: change the phrase "markdown code fences" to "Markdown code fences" (capitalize Markdown) and change "multi region endpoints" to "multi-region endpoints" (add hyphen); locate and edit the occurrences matching those exact snippets to preserve surrounding text and punctuation.
110-196:⚠️ Potential issue | 🟡 MinorHistorical sections still unresolved — version gap and duplicate content persist.
A previous review flagged these concerns (marked "✅ Addressed in commit d511360"), but the sections remain unchanged:
- Duplicate content –
## 22.1.0(lines 117–123) is nearly verbatim identical to## 2.3.0(lines 25–31).## 22.0.0(lines 127–130) repeats the first three bullets of## 2.2.0(lines 35–39).- Unexplained version gap – The changelog jumps from
1.5.0directly to22.3.1with no bridging note. If these entries genuinely belong to a prior versioning scheme for this SDK, a short header (e.g.,## Historical versions (pre-1.x renumber)) would prevent reader confusion. If they belong to a different SDK (e.g.,sdk-for-web), they should be removed.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@CHANGELOG.md` around lines 110 - 196, The changelog contains duplicate entries and an unexplained version jump: deduplicate the repeated sections by removing or merging the near-identical blocks under headings "## 22.1.0" and "## 2.3.0" and likewise reconcile "## 22.0.0" with "## 2.2.0"; add a short clarifying header (e.g., "## Historical versions (pre-1.x renumber)") above "## 22.3.1" or move these entries into a clearly labeled historical section if they belong to a different SDK, and ensure continuity by adding a bridging note after "## 1.5.0" if these are intentionally renumbered rather than deleting any content; locate the affected headings "## 22.3.1", "## 22.1.0", "## 22.0.0", "## 2.3.0", "## 2.2.0", and "## 1.5.0" to make the edits.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@CHANGELOG.md`:
- Line 123: Update the two prose issues in CHANGELOG.md: change the phrase
"markdown code fences" to "Markdown code fences" (capitalize Markdown) and
change "multi region endpoints" to "multi-region endpoints" (add hyphen); locate
and edit the occurrences matching those exact snippets to preserve surrounding
text and punctuation.
- Around line 110-196: The changelog contains duplicate entries and an
unexplained version jump: deduplicate the repeated sections by removing or
merging the near-identical blocks under headings "## 22.1.0" and "## 2.3.0" and
likewise reconcile "## 22.0.0" with "## 2.2.0"; add a short clarifying header
(e.g., "## Historical versions (pre-1.x renumber)") above "## 22.3.1" or move
these entries into a clearly labeled historical section if they belong to a
different SDK, and ensure continuity by adding a bridging note after "## 1.5.0"
if these are intentionally renumbered rather than deleting any content; locate
the affected headings "## 22.3.1", "## 22.1.0", "## 22.0.0", "## 2.3.0", "##
2.2.0", and "## 1.5.0" to make the edits.
1 participant
This PR contains updates to the Console SDK for version 3.2.0.
Summary by CodeRabbit
Release Notes
New Features
Chores