-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to Smallrye Fault Tolerance 6.5.0 and resolve FT methods during build #43833
Conversation
Ladicek
commented
Oct 11, 2024
•
edited
Loading
edited
- https://smallrye.io/blog/fault-tolerance-6-5-0/
Thanks for your pull request! Your pull request does not follow our editorial rules. Could you have a look?
This message is automatically generated by a bot. |
This builds on a new feature of SmallRye Fault Tolerance 6.5.0, which requires fault tolerance methods to be resolved during deployment -- which means at build time in Quarkus. This is what most of the changes in this PR relate to. CC @zakkak -- this is what we discussed a while ago (see also #42229). |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. I just want to check with @radcortez that we are OK partially updating to next MicroProfile in 3.16 (because my understanding is that it's what we do here, correct me if I'm mistaken).
Yeah, that's right. MP FT 4.1 is part of MicroProfile 7.0. I don't think we've coordinated updates in the past, but if @radcortez wants, this can certainly wait. |
.../src/main/java/io/quarkus/smallrye/faulttolerance/deployment/FaultToleranceMethodSearch.java
Show resolved
Hide resolved
…o implements annotation members
This commit includes build-time resolution of fault tolerance methods (`@Fallback.fallbackMethod()`, `@BeforeRetry.methodName()`). This means that the corresponding configuration properties are now build-time only, instead of runtime. This is a breaking change, but since we need to register these methods for reflection for native image compilation, there's unfortunately no other way.
53bbf9c
to
0a67472
Compare
Yes, it is ok. Currently, we stopped being compatible some versions ago with the OTel updates, so it's not a big deal. We do have to ensure that we are able to sync all the work in one of our releases so we can certify again. |
Status for workflow
|
Status | Name | Step | Failures | Logs | Raw logs | Build scan |
---|---|---|---|---|---|---|
✖ | JVM Tests - JDK 17 | Build |
Failures | Logs | Raw logs | 🔍 |
✖ | JVM Tests - JDK 21 | Build |
Failures | Logs | Raw logs | 🔍 |
You can consult the Develocity build scans.
Failures
⚙️ JVM Tests - JDK 17 #
- Failing: integration-tests/redis-client
📦 integration-tests/redis-client
✖ Failed to execute goal io.fabric8:docker-maven-plugin:0.45.1:start (docker-start) on project quarkus-integration-test-redis-client: I/O Error
⚙️ JVM Tests - JDK 21 #
- Failing: integration-tests/logging-gelf
📦 integration-tests/logging-gelf
✖ Failed to execute goal io.fabric8:docker-maven-plugin:0.45.1:start (docker-start) on project quarkus-integration-test-logging-gelf: I/O Error
Flaky tests - Develocity
⚙️ Gradle Tests - JDK 17 Windows
📦 integration-tests/gradle
✖ io.quarkus.gradle.devmode.KotlinProjectWithCompilerArgsDevModeTest.main
- History
Condition with Lambda expression in io.quarkus.test.devmode.util.DevModeClient was not fulfilled within 2 minutes.
-org.awaitility.core.ConditionTimeoutException
org.awaitility.core.ConditionTimeoutException: Condition with Lambda expression in io.quarkus.test.devmode.util.DevModeClient was not fulfilled within 2 minutes.
at app//org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
at app//org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
at app//org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
at app//org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1006)
at app//org.awaitility.core.ConditionFactory.until(ConditionFactory.java:975)
at app//io.quarkus.test.devmode.util.DevModeClient.getHttpResponse(DevModeClient.java:164)
at app//io.quarkus.gradle.devmode.QuarkusDevGradleTestBase.getHttpResponse(QuarkusDevGradleTestBase.java:164)
CI failures were unrelated. |