-
Notifications
You must be signed in to change notification settings - Fork 27
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
CORE-17387 - flow checkpoint maintenance events #4746
Conversation
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. |
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.
@conalsmith-r3 , @jujoramos please advice here.
I think we need a ConfigKey
for the StateManager.
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.
I've created a ticket for this already 👍 .
// 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 |
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.
@jujoramos , @conalsmith-r3 , please advice how this can be implemented.
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.
We haven't implemented custom filters yet, but there's already a ticket created for it.
// TODO - return an avro message (schema TBC) for each checkpoint | ||
// TODO - define topic to publish message on |
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.
@JamesHR3 , should this be a new topic?
Do we know yet what the schema for the message needs to look like?
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.
I know it's still in draft and some changes are blocked by the state manager implementation, just leaving some comments.
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. |
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.
I've created a ticket for this already 👍 .
// 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 |
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.
We haven't implemented custom filters yet, but there's already a ticket created for it.
51ece0e
to
d73c655
Compare
…tests that need it.
- Fix FlowServiceTest
…ect. - Fix Metadata so it's an immutable map. - Add tests for Metadata checks.
d73c655
to
297c5ba
Compare
Jenkins build for PR 4746 build 16 Build Successful: |
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.
LGTM, just some minor comments.
components/flow/flow-service/src/main/kotlin/net/corda/flow/maintenance/FlowMaintenanceImpl.kt
Show resolved
Hide resolved
assertDoesNotThrow { | ||
Metadata(mapOf("foo" to value)) | ||
} |
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.
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
).
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.
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:
I agree it technically doesn't make much difference, but semantically maybe it does.
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.
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()
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 |
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.
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)?
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.
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.
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.
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.
...e-manager/state-manager-api/src/test/kotlin/net/corda/libs/statemanager/api/MetadataTests.kt
Outdated
Show resolved
Hide resolved
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.
Couple of nitpicking things but looks good.
.../state-manager/state-manager-api/src/main/kotlin/net/corda/libs/statemanager/api/Metadata.kt
Show resolved
Hide resolved
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.
LGTM - build files
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.
Ledger changes are fine
3e81936
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.
Re-approved for ledger
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.
LGTM - build files
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