chore: fetch upstream commits#4
Merged
Merged
Conversation
Adding the repository in the Cargo.toml file will give greater accessability to this Crate's source code to its users. Closes cloudflare#235
Does the following: - Removes the `multiple_railguns_allowed` field, as it appears to be removed. Fixes cloudflare#236 - Makes the fields of the `owner` field optional (cloudflare#232), as otherwise the examples would still not work - Adds the `activated_on` field There are some more discrepancies, i.e. fields on the docs that don't exist here, and fields here that don't exist in the docs, but I want to refrain from changing too much. This can be tested with the `cloudflare-examples` cli: <details> <summary>Before</summary> ``` $ cargo run --bin cloudflare-examples -- --auth-token=XXX zone XXX Compiling cloudflare v0.12.0 (/home/wp/programming/cloudflare-rs/cloudflare) Compiling cloudflare-examples v0.6.0 (/home/wp/programming/cloudflare-rs/cloudflare-examples) Finished dev [unoptimized + debuginfo] target(s) in 3.45s Running `target/debug/cloudflare-examples --auth-token=XXX zone XXX` Error: error decoding response body: missing field `multiple_railguns_allowed` at line 1 column 585 ``` </details> <details> <summary>After</summary> ``` $cargo run --bin cloudflare-examples -- --auth-token=XXX zone XXX Finished dev [unoptimized + debuginfo] target(s) in 0.11s Running `target/debug/cloudflare-examples --auth-token=XXX zone XXX` Success: ApiSuccess { result: Zone { id: "XXX", name: "XXX", account: AccountDetails { id: "XXX", name: "XXX", }, activated_on: 2021-08-22T18:52:08.877823Z, betas: None, created_on: 2021-08-22T18:48:11.312863Z, deactivation_reason: None, development_mode: 0, host: None, meta: Meta { custom_certificate_quota: 0, page_rule_quota: 3, phishing_detected: false, }, modified_on: 2021-08-22T18:52:08.877823Z, name_servers: [ "pedro.ns.cloudflare.com", "surina.ns.cloudflare.com", ], original_dnshost: None, original_name_servers: Some( [ "ns13.domaincontrol.com", "ns14.domaincontrol.com", ], ), original_registrar: Some( "namecheap, inc. (id: 1068)", ), owner: User { id: None, email: None, }, paused: false, permissions: [ "#dns_records:edit", "#dns_records:read", "#zone:read", ], plan: Some( Plan { id: "0feeeeeeeeeeeeeeeeeeeeeeeeeeeeee", name: "Free Website", price: 0.0, currency: "USD", frequency: Some( Nil, ), legacy_id: "free", is_subscribed: false, can_subscribe: false, }, ), plan_pending: None, status: Active, vanity_name_servers: None, zone_type: Full, }, result_info: None, messages: Array [], errors: [], } ``` </details>
…flare#253) As https://developers.cloudflare.com/changelog/ said on 27th, Jan, 2025, "Records returned by the API will no longer contain the zone_id and zone_name fields.", so we need to remove it to avoid parse error. ref cloudflare#251 Signed-off-by: Woshiluo Luo <woshiluo.luo@outlook.com>
- Update a few dependencies - Add @kennetheversole to the authors - Release `0.13.0`
This adds support for the execute model endpoint, as described here: https://developers.cloudflare.com/api/resources/ai/methods/run/ This also adds an optional feature `ndarray` that can deserialize embeddings directly into an `ndarray::ArrayD`.
…udflare#259) # Changes ## Features ### Add the ability for an endpoint to receive raw data This was made by: * adding a flag that defaults to `false`, that represents whether the endpoint responds with raw bytes data or JSON (ApiSuccess); * adding two types that represents the response type : * what the JSON deserialization should expect to get; * the actual response type that the user will get. The presence of those types is necessary if we want users to be able to directly get the actual endpoint response type on their request. Since Rust doesn't allow default type parameters yet, it is true that we will have to manually set those types for each new endpoint in the future, but I believe it's a fair trade-off for better user experience. Note that all existing endpoints have already been updated. ### Implement multipart body support Endpoint bodies can now send `multipart/form-data` content type. This was implemented by adding a `RequestBody` enum, which is either `Json`, `Raw` or `Multipart`. The Client's `request` function can then match on `endpoint.body`. A `MultipartBody` trait had to be created to circumvent the fact that `reqwest`'s `blocking::multipart::Form`/`Part` and `async_impl::multipart::Form`/`Part` aren't inter-compatible, and no `From` or `Into` exists between the two. It consists of a `parts` function that returns a vector containing the parts of the multipart body. Every endpoint that has the option to send a multipart body has to implement it. All existing multipart endpoints have already been updated. ### Implement missing endpoints in workerskv * Get Namespace * Read Key * Read Key Metadata * Write Key ## Refactoring * Some blocks of code weren't in their associated module or file. * Blocking API tests and functions are now in `blocking_api.rs`. * the feature/target_arch check is now in the module definition * `ApiResult` is now in `response/mod.rs`. * DNS, Zone, Plan, R2 and User endpoints are now in their own module. * API Clients are now in their own module. * `ApiFailure` tests are now in `api_fail.rs`. * Change/Rename types according to the official API documentation: * `ApiError` is now named `ResponseInfo`, which is the same type as `ApiSuccess.messages`. * Remove unused feature "endpoint-spec" in `framework/endpoint.rs`. * Switch from `percent-encoding` to `urlencoding`, which allows us to get rid of `PATH_SEGMENT_ENCODE_SET`. * Elide lifetimes when possible. ## Documentation ### Docstrings I updated every docstrings of the `workerskv` module endpoints to reflect the official API documentation. The other endpoints are still to be done in the future, but I focused on the KV module here. ## Tests ### Async Client Unit tests I added unit tests to the async client: * Successful JSON response handling; * Successful raw response handling; * Handling of an endpoint returning an error; * Test an endpoint that returns nothing; * Test sending a JSON request body; * Test sending a raw byte request body; * Test sending a multipart request; * Test sending a request with query parameters. #### Blocking Client I need help finding a way to use refactor those tests to use them in the blocking client as well, without just copying them over. #### Mockito Issues To check test multipart body endpoint, I had to use a regex that apparently wasn't supported by `mockito::Matcher::Regex`, which led to the update of `mockito` to have access to `.match_request()` and check the regex there. The latest versions of `mockito` uses a server pool. Thus, `mockito::server_url()` doesn't exist anymore. This isn't an issue for the main crate : I removed `Environment::Mockito`, and users can use `Environment::Custom` to configure the client with `mockito`'s server. But it isn't compatible with current implementation of `cloudflare-examples`. ##### Next steps I didn't update the `cloudflare-examples` code yet. I can update it in a next PR, but it works as is at the moment, so it isn't a priority. ### Integration Tests I added an integration test suite for the `workerskv` module. ## Fixes I added vector length validation on write and delete bulk KV. I need help finding a way to validate the request size of the write bulk endpoint, as expected and documented in the official API docs. # Next Steps While working on this PR, I encountered things I think we should discuss further. I'm going to create an issue for all of them, but here's a summary if you find it necessary to discuss before squash & merge this PR: * There are ambiguities in the types, comparing to both the official documentation and what we're actually getting on the endpoint. Should we match the former to align with the docs, or the latter to align with reality? * `workerskv::WorkersKvBulkResult`: `unsuccessful_keys` does not seem to be optional. Rather, we just get an empty vector if the list is empty. * `workerskv::write_bulk::KeyValuePair` doesn't reflect the official documentation, but neither does this one make sense either. Having everything optional isn't right. What should we do? * `zone::Zone`: `plan` doesn't appear in the documentation, neither does it appear in the official TypeScript library. What should we do? * Argo Tunnels have been renamed to `Cloudflare Tunnels`. `cfd_tunnels` has a lot of the same code as `argo_tunnels`. Should we remove `argo_tunnels` altogether? * Shouldn't we rename the clients to `AsyncClient` and `BlockingClient`? # Closing remarks I mainly focused on working in getting the `workerskv` module complete and working because I needed it for a project, but I'd love to further contribute and see this crate being as complete as the official TypeScript library. I'm planning on going over each endpoint "group" in the official documentation and implementing them all, module by module. If you have any comments or remarks, don't hesitate to let me know. @kennetheversole I'm tagging you, after seeing you asked to be tagged in another PR. Thanks in advance for your review and help on this. Closes cloudflare#14, closes cloudflare#26
Updating Semgrep.yml file - Semgrep is a tool that will be used to scan Cloudflare's public repos for Supply chain, code and secrets. This work is part of Application & Product Security team's initiative to onboard Semgrep onto all of Cloudflare's public repos. In case of any questions, please reach out to "Hrushikesh Deshpande" on cf internal chat.
Currently the `WorkersBinding` assume that it always have `namespace_id` and also does not take into consideration all the other possible fields of different bindings. This changes so that the `WorkerBinding` is now an enum with all the possible options listed on https://developers.cloudflare.com/workers/configuration/multipart-upload-metadata/#bindings. Closes cloudflare#261
Prep Release 0.14.0.
) It was priorly impossible to construct these structs due to the private members. I don't see any reason they should have been private in the first place. FYI @kennetheversole (bugged you internally about this)
Minor Release
r-birkner
approved these changes
May 28, 2026
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
12 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.
Note: the linters workflow also failed upstream (PR).