-
Notifications
You must be signed in to change notification settings - Fork 39
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
feat(sdk): adding verification expression #1332
Conversation
...rs/slack/src/main/java/io/camunda/connector/slack/inbound/SlackInboundWebhookExecutable.java
Show resolved
Hide resolved
...ector-sdk/core/src/main/java/io/camunda/connector/api/inbound/webhook/VerifiableWebhook.java
Outdated
Show resolved
Hide resolved
...src/main/java/io/camunda/connector/runtime/inbound/webhook/InboundWebhookRestController.java
Outdated
Show resolved
Hide resolved
...src/main/java/io/camunda/connector/runtime/inbound/webhook/InboundWebhookRestController.java
Outdated
Show resolved
Hide resolved
28bb084
to
68312ff
Compare
68312ff
to
d4e79e5
Compare
Optional.of(verificationResult) | ||
.map(VerifiableWebhook.WebhookHttpVerificationResult::headers) | ||
.ifPresent(map -> map.forEach(headers::add)); |
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.
Shouldnt it rather be Optional.of(verificationResult.headers())
?
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 it would be Optional.ofNullable(...)
. But in that case it's the same.
protected ResponseEntity buildBodyExpressionResponseOrOk( | ||
WebhookResult webhookResult, WebhookResultContext processVariablesContext) { | ||
if (webhookResult.responseBodyExpression() != null) { | ||
var httpResponseData = webhookResult.responseBodyExpression().apply(processVariablesContext); |
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.
Couldnt this throw an exception?
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.
Very much depends on the fucntion implementation. The method call is covered behind try-catch
.
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.
@sbuettner do you have any specific issue in mind?
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.
Not really but usually we catch exceptions where they happen.
return ResponseEntity.ok(httpResponseData); | ||
} else { | ||
return ResponseEntity.ok().build(); |
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.
Please avoid multiple return statements.
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.
Reworked this and other methods. I am generally okay with multiple ret
s. I am wondering, why don't you like multiple return
statements? We agreed on Google Java Code Style but it says nothing about returns.
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 think its usually (not always) easier to follow but we can also discuss with the team.
...src/main/java/io/camunda/connector/runtime/inbound/webhook/InboundWebhookRestController.java
Outdated
Show resolved
Hide resolved
d4e79e5
to
529f654
Compare
529f654
to
3e518ca
Compare
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 a minor comment to the test case
@@ -195,4 +213,6 @@ private record TargetTypeInteger(Function<InputContextInteger, Integer> function | |||
private record TargetTypeList(Function<InputContextInteger, List<Long>> function) {} | |||
|
|||
private record TargetTypeMap(Function<InputContextInteger, Map<String, Long>> function) {} | |||
|
|||
private record TargetTypeFoldedMap(Function<InputContextInteger, Map<String, Object>> function) {} |
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.
nit:
The original issue actually involved an Object
return type that contained a map as one of its fields, right? I think it might be more representative to test the similar use case here:
private record FoldedMapRecord(Map<String, Object> folded) {}
private record TargetTypeFoldedMap(Function<InputContextInteger, FoldedMapRecord> function) {}
The reason this caught my eye, I think the current test case could have been handled by the previous implementation as well (by this code, as the root type is already a map). But I might be wrong here.
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.
Spent some time trying to rewrite and didn't manage to make it working 😕
Let me merge it as-is now, and I'll follow up on this in this task.
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.
Sure, thank you!
Description
feat(sdk): adding verification expression