[pull] main from appwrite:main - #218
Merged
Merged
Conversation
Transaction log queries can be SDK JSON strings or already-decoded
{method, attribute, values} arrays. Query::parseQueries() always calls
parse(string), which TypeErrors on arrays during commit.
Parse each stored query with parseQuery() or parse() so valid array
queries commit successfully. Apply the same handling when replaying
logs in TransactionState.
Fixes CLOUD-3QMK
Co-authored-by: Chirag Aggarwal <chiragaggarwal5k@gmail.com>
The OpenAPI3 parameter switch matches on the concrete validator class, so Utopia\Validator\JSON\FCM fell through to the string default even though it reports TYPE_OBJECT and the controller still accepts an array, stdClass or JSON string. Swapping the FCM param's JSON validator for the stricter FCM one was meant to tighten validation, but it silently narrowed the published type and turned serviceAccountJSON into a string in every generated SDK.
…fault Rather than adding one more class to the object case, the default branch now emits an object when the validator reports TYPE_OBJECT, so the next object validator without a case of its own does not regress the same way. The listed cases keep their current behaviour: Assoc reports TYPE_ARRAY but is deliberately published as an object, and a type-driven rule applied to them would change that. Across the full cloud route table this changes exactly the two FCM parameters and nothing else.
JSON and JSON\ObjectValidator both report TYPE_OBJECT, so the default emits exactly what their cases did. Assoc keeps its case because it reports TYPE_ARRAY and is published as an object on purpose.
Both GitLab surfaces hardcoded https://gitlab.com, so a self-hosted GitLab could not be used for either repository integration or console sign-in. _APP_VCS_GITLAB_ENDPOINT covers repository integration: the vcs registry entry Vcs\Factory hands to setEndpoint() and to the OAuth2 builder, plus the authorize and callback handlers that build their own client. _APP_CONSOLE_GITLAB_ENDPOINT covers console sign-in. Auth\OAuth2\Gitlab reads its endpoint out of a JSON-encoded secret, so gitlabSecret now carries {"clientSecret","endpoint"} rather than the raw secret string. That also fixes console sign-in outright, which threw "Invalid secret" on the undecodable plain string. The value stays empty when unconfigured so account.php keeps reporting the provider as disabled. Both default to https://gitlab.com.
getAppSecret() decoded appSecret with JSON_THROW_ON_ERROR and turned any failure into "Invalid secret", so a secret that is not a JSON object took down every call that needed it. The legacy PATCH /v1/projects/:projectId/oauth2 writes the secret verbatim for any provider in the oAuthProviders config, gitlab included, so projects configured through it fail sign-in outright. A numeric secret decoded fine and then tripped the array return type instead. Fall back to treating the raw string as the client secret, matching Google, which grew the same fallback for the same reason. Also rtrim the endpoint, as Gitea's setEndpoint() does, so a configured endpoint with a trailing slash no longer builds //oauth/authorize.
…te-collection-integer-format-options
…te-collection-integer-format-options
System::getEnv is getenv($name) ?: $default, so a set-but-empty variable falls through to the https://gitlab.com default the config already carries. Shipping the value blank keeps the sample env and a generated install free of a URL that only self-hosted GitLab needs to change, matching the Gitea endpoint entry. The effective default moves into the descriptions.
feat: make the GitLab endpoint configurable
…mat-options Column boundaries for Integer attributes
…uery-parse-44d3 Fix TypeError committing transaction bulkDelete with array queries
…on-spec-type fix(spec): emit object-typed validators as objects, not strings
…ate SDK methods The createDocument and createDocuments routes for DocumentsDB and VectorsDB already accept a transactionId body parameter, but their SDK Method definitions omit it from the parameter allow-list, so the generated SDKs cannot stage document creation inside a transaction. TablesDB's createRow and createRows already list it. Mirror that here.
Lock createDocument/createDocuments SDK method metadata so generated clients keep transactionId, and reject unknown transaction IDs on the create and bulk-create routes. Co-authored-by: Jake Barnby <abnegate@users.noreply.github.com>
Co-authored-by: Jake Barnby <abnegate@users.noreply.github.com>
Keep transactionId create coverage in the existing e2e txn suites. Co-authored-by: Jake Barnby <abnegate@users.noreply.github.com>
…ate-transaction-id fix(databases): expose transactionId on DocumentsDB and VectorsDB create SDK methods
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )