Skip to content
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

CORE-17387 - flow checkpoint maintenance events #4746

Conversation

driessamyn
Copy link
Contributor

@driessamyn driessamyn commented Sep 30, 2023

Create a component in the flow service responsible for processing scheduled task triggers and generating checkpoint maintenance events.
This includes integration with the State Manager component and as this is the first component that uses it, this change includes a number of small changes to that library.

API change: corda/corda-api#1272

private val coordinator = coordinatorFactory.createCoordinator<FlowExecutor>(::eventHandler)
override fun onConfigChange(config: Map<String, SmartConfig>) {
val messagingConfig = config.getConfig(ConfigKeys.MESSAGING_CONFIG)
// TODO - fix config key. The state manager has nothing to do with messaging.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@conalsmith-r3 , @jujoramos please advice here.
I think we need a ConfigKey for the StateManager.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've created a ticket for this already 👍 .

Comment on lines +30 to +35
// TODO - we must be able to specify additional filters so we can limit to selecting those sessions that are still open
// TODO - we must be able to limit by type of state
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jujoramos , @conalsmith-r3 , please advice how this can be implemented.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We haven't implemented custom filters yet, but there's already a ticket created for it.

Comment on lines 39 to 40
// TODO - return an avro message (schema TBC) for each checkpoint
// TODO - define topic to publish message on
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JamesHR3 , should this be a new topic?
Do we know yet what the schema for the message needs to look like?

Copy link
Contributor

@jujoramos jujoramos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it's still in draft and some changes are blocked by the state manager implementation, just leaving some comments.

applications/examples/sandbox-app/build.gradle Outdated Show resolved Hide resolved
private val coordinator = coordinatorFactory.createCoordinator<FlowExecutor>(::eventHandler)
override fun onConfigChange(config: Map<String, SmartConfig>) {
val messagingConfig = config.getConfig(ConfigKeys.MESSAGING_CONFIG)
// TODO - fix config key. The state manager has nothing to do with messaging.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've created a ticket for this already 👍 .

Comment on lines +30 to +35
// TODO - we must be able to specify additional filters so we can limit to selecting those sessions that are still open
// TODO - we must be able to limit by type of state
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We haven't implemented custom filters yet, but there's already a ticket created for it.

components/ledger/ledger-common-flow/build.gradle Outdated Show resolved Hide resolved
components/ledger/ledger-consensual-flow/build.gradle Outdated Show resolved Hide resolved
components/ledger/ledger-utxo-flow/build.gradle Outdated Show resolved Hide resolved
@driessamyn driessamyn force-pushed the driessamyn/CORE-17387/flow-checkpoint-maintenance-events branch from 51ece0e to d73c655 Compare October 2, 2023 15:18
@driessamyn driessamyn force-pushed the driessamyn/CORE-17387/flow-checkpoint-maintenance-events branch from d73c655 to 297c5ba Compare October 2, 2023 15:42
@driessamyn driessamyn requested a review from JamesHR3 October 2, 2023 15:54
@corda-jenkins-ci02
Copy link
Contributor

corda-jenkins-ci02 bot commented Oct 2, 2023

Jenkins build for PR 4746 build 16

Build Successful:
Jar artifact version produced by this PR: 5.1.0.0-alpha-1696347157836
Helm chart version produced by this PR: 5.1.0-alpha.1696347157836
Helm chart pushed to: oci://corda-os-docker-dev.software.r3.com/helm-charts/pr-4746/corda

@driessamyn driessamyn marked this pull request as ready for review October 2, 2023 19:03
@driessamyn driessamyn requested review from a team as code owners October 2, 2023 19:03
jujoramos
jujoramos previously approved these changes Oct 3, 2023
Copy link
Contributor

@jujoramos jujoramos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just some minor comments.

components/flow/flow-service/build.gradle Show resolved Hide resolved
Comment on lines +24 to +26
assertDoesNotThrow {
Metadata(mapOf("foo" to value))
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: why the assertDoesNotThrow{} here?, if the exception is thrown the test will fail anyways (and removing it also removes an unneeded dependency to jupiter).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It just makes it more explicit I guess.
The test framework does threat the 2 things different (test failed vs error).
E.g.

@Test
    fun foo() {
        throw IllegalArgumentException("foo")
    }

    @Test
    fun bar() {
        assertDoesNotThrow {
            throw IllegalArgumentException("bar")
        }
    }

results in:

image

I agree it technically doesn't make much difference, but semantically maybe it does.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, and just to keep consistency across this single test (use single assertion library), I would use something like the following:

assertThatCode {
   Metadata(mapOf("foo" to value))
}.doesNotThrowAnyException()

Comment on lines 3 to 6
import org.assertj.core.api.Assertions.assertThat
import org.junit.jupiter.api.Test
import org.junit.jupiter.api.assertDoesNotThrow
import org.junit.jupiter.api.assertThrows
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: we are mixing two assertions libraries in the test, can we use only one (`assert4j would be my preferred choice but it's up to you)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the assertThrows syntax is a bit more natural than assertJ's assertThatThrownBy and is more common across the codebase:

❯ grep -r --include "*.kt" assertThat | wc -l
    9129
❯ grep -r --include "*.kt" assertThrows | wc -l
    1792
❯ grep -r --include "*.kt" assertThatThrownBy | wc -l
     369

Both libraries seem to be used widely, with a slight preference for the junit assertions according to the imports:

❯ grep -r --include "*.kt" "import org.assertj.core.api.Assertions" | wc -l
     852
❯ grep -r --include "*.kt" "import org.junit.jupiter.api.assert" | wc -l
    1169

I don't really mind. I don't mind we settle to use one, but using multiple equally doesn't bother me as long as the code is readable.

Copy link
Contributor

@jujoramos jujoramos Oct 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, but I'd argue that we should keep consistency and use a single assertions framework per test class, even though we are not consistent across the codebase.

Copy link
Collaborator

@JamesHR3 JamesHR3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of nitpicking things but looks good.

@driessamyn driessamyn requested a review from JamesHR3 October 3, 2023 12:16
@driessamyn driessamyn requested a review from jujoramos October 3, 2023 12:16
JamesHR3
JamesHR3 previously approved these changes Oct 3, 2023
mag1c-48
mag1c-48 previously approved these changes Oct 3, 2023
Copy link
Contributor

@mag1c-48 mag1c-48 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - build files

blsemo
blsemo previously approved these changes Oct 3, 2023
Copy link
Contributor

@blsemo blsemo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ledger changes are fine

jujoramos
jujoramos previously approved these changes Oct 3, 2023
@driessamyn driessamyn dismissed stale reviews from jujoramos, blsemo, mag1c-48, and JamesHR3 via 3e81936 October 3, 2023 14:55
Copy link
Contributor

@blsemo blsemo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-approved for ledger

Copy link
Contributor

@mcgovc mcgovc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - build files

@driessamyn driessamyn requested a review from mag1c-48 October 3, 2023 16:52
@driessamyn driessamyn merged commit 6a29a06 into release/os/5.1 Oct 3, 2023
1 check passed
@driessamyn driessamyn deleted the driessamyn/CORE-17387/flow-checkpoint-maintenance-events branch October 3, 2023 16:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants