Conversation
… transitive) Spring Boot's BOM already imports the matching spring-framework-bom transitively. The explicit import was double-pinning the Spring Framework version and would have required override during framework matrix tests. Effective Spring Framework version is unchanged (7.0.8, sourced via spring-boot-dependencies).
Replaces the per-PR framework-matrix job (which used hardcoded versions and never caught upstream regressions) with a separate weekly workflow that queries Maven Central for the LATEST patch versions of Spring Boot 4.0/4.1 and Quarkus 3.33 LTS/3.35 and runs the full test suite against the 4 latest-patch combinations. Runs every Monday 06:00 UTC and on-demand via workflow_dispatch. fail-fast: false so one broken cell does not hide the others. On scheduled failure, auto-creates an issue with the 'compat-regression' label so the reviewer can triage upstream regressions promptly.
Publishes docs/compatibility.md documenting which framework combinations Ark 1.0.x supports. The default Spring Boot + Quarkus combination is verified on every PR; the latest-patch combinations of Spring Boot 4.0/ 4.1 and Quarkus 3.33 LTS/3.35 are verified weekly by the compat-weekly workflow. Status tiers: 'Verified on every PR', 'Verified weekly', 'Untested', 'Known-broken'.
Adds compat-weekly workflow as a callable target and invokes it from prepare-release.yml's compat job (runs in parallel with test). The release PR is only opened if both Java matrix and framework-matrix pass. This catches the case where an upstream Spring Boot or Quarkus patch regression slipped through between cron runs — release is blocked until either the regression is fixed or the compat matrix is updated to mark the affected cell as Known-broken.
Previously, deploy-snapshot tried to publish every push to main to the
Nexus snapshot repo, gated only by a brittle commit-message filter
(if: !contains(message, 'Release v')). That filter failed to match
prepare-release.yml's actual commit subject ('chore(release): prepare
v1.0.7 (#88)'), so release-prep PR merges triggered deploys that pushed
non-SNAPSHOT versions to a snapshot repo. Nexus rejected those, leaving
red CI runs that needed manual triage.
Replaces the commit-message filter with a preflight job that reads the
project version from pom.xml. If it ends in -SNAPSHOT, the test and
deploy jobs proceed; otherwise both are skipped and the run completes
green with a notice annotation explaining what was decided.
Source of truth is now the artifact being deployed, not the commit
message.
…ntRequest Adds a per-request 'throwOnError' field to AbstractClientRequest (default true, preserves current behavior). validateResponse() now short-circuits when the flag is false, letting the caller inspect the response regardless of status. Fluent opt-out: request.noThrow(). Protected setter throwOnError(boolean) is used by AbstractArkClient to apply the client-level default after request construction. AbstractArkBuilder gains throwOnError(boolean) so users can change the default across all requests on a single client. This commit leaves AbstractArkClient's constructor breaking (new param) and each *ArkClient subclass will be updated in Phase B.
…rowOnError builder option Each execution model's request interface (sync, async, reactor, mutiny, vertx) now declares noThrow() returning its own type for fluent chaining. The implementation is inherited from AbstractClientRequest — no per-implementation changes. Each *ArkClient's createRequest() applies the client-level throwOnErrorDefault to the new request before returning. Updates AbstractArkClientTest stub to thread the new constructor parameter so the build compiles after the AbstractArkClient signature change introduced in the previous commit.
… + client-level default Adds 4 tests per execution model (20 total) covering: - default behavior: 4xx/5xx throws ApiException (unchanged) - per-request .noThrow(): response returned, status preserved - client-level throwOnError(false): all requests on that client permissive - combined: client default wins when request does not call .noThrow() Adds Permissive error handling section to each execution model doc (sync.md, async.md, reactor.md, mutiny.md) and a feature bullet in README.md.
…entFactoryBean (sync + webflux) Adds @DefaultValue("true") boolean throwOnError to ClientProperties in both ArkProperties (sync) and ArkWebFluxProperties (webflux). Default true preserves current behavior. ArkClientFactoryBean and ArkWebFluxClientFactoryBean apply the value to the underlying builder via builder.throwOnError(props.throwOnError()), threading the per-client config down to the runtime client instance. Allows @RegisterArkClient users to configure permissive error handling declaratively: ark.client.users-api.throw-on-error=false
…a ArkRecorder Adds @withname("throw-on-error") @WithDefault("true") boolean throwOnError() to ArkClientNamedConfig and threads the value through ArkRecorder to the underlying client builder. Allows @RegisterArkClient users on Quarkus to configure permissive error handling declaratively: ark.client."users-api".throw-on-error=false
… guides Adds throw-on-error row to the per-client properties table in docs/spring-boot.md (and docs/quarkus*.md if it exists), pointing at the Permissive error handling section in sync.md for examples.
…execution models Adds a public raw() method to each *ClientResponse interface returning the underlying RawResponse (sync), CompletableFuture<RawResponse> (async), Mono<RawResponse> (reactor), Uni<RawResponse> (mutiny), or io.vertx.core.Future<RawResponse> (vertx). Each Default*ClientResponse already holds the raw payload as a field — this exposes it via the public API. Useful in combination with .noThrow() or client-level throwOnError(false): callers can inspect status, headers, and the raw body String regardless of HTTP status, without going through type-based deserialization.
…uto-noThrow + retrieve raw)
Each execution-model ReturnTypeHandler now detects RawResponse (or
CompletableFuture<RawResponse> / Mono<RawResponse> / Uni<RawResponse>)
as a valid proxy return type and:
1. Toggles per-request noThrow so HTTP 4xx/5xx do not raise ApiException
before the handler can return — opting into raw mode implies the
caller wants to inspect the response regardless of status.
2. Calls retrieve().raw() instead of retrieve().body(type), returning the
raw response wrapper instead of going through deserialization.
The auto-noThrow only applies when the return type is RawResponse — other
return types on the same client preserve the configured default.
Enables @RegisterArkClient interfaces to declare methods like:
@GetExchange("/{id}")
RawResponse getUserRaw(@PathVariable String id);
without setting throw-on-error=false at the client level.
Note: Vert.x execution model has no return-type handler today, so this
change is limited to sync/async/reactor/mutiny.
…n type Adds 3 tests per execution model (15 total): - fluent .raw() happy path (200 — body matches transport output) - fluent .raw() with .noThrow() on 4xx (404 — returns wrapper, no throw) - proxy RawResponse return type — auto-noThrow + status/body inspectable (Vert.x has no proxy handler today, so its third test exercises the client-level throwOnError(false) path with .raw() instead) Docs additions: - "Capturing the raw response" section in sync.md, async.md, reactor.md, mutiny.md - "RawResponse as a return type" section in declarative-spring.md and quarkus-jackson.md - README feature bullet
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
1 participant
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.
No description provided.