Spring Cloud Contract returns "cursor" in the response payload for elements with regex - spring-cloud-contract

I have a java based service as the provider and a node JS app as the consumer.
I used a stub runner here https://github.com/spring-cloud-samples/stub-runner-boot for Node JS to run against the wiremock. But whether it's Node JS, browser or curl as client I get this "cursor" text in place of generated string from regex elements.
This is the contract:
request {
method GET()
url value(consumer(regex('/v2/accounts/[0-9]+')))
}
response {
status 200
headers {
contentType(applicationJson())
}
body (
"firstName": regex('[a-zA-Z]*'),
"lastName": regex('[a-zA-Z]*'),
"kycStatus": regex('FAILED|PASSED|PENDING|ERROR'),
"address": [
"streetAddress" : "3244 jackson street",
"city" : "City",
"state" : regex('[a-zA-Z]{2}'),
"zipcode": regex('^\\d{5}\$')
]
)
}
This is the actual response from wiremock:
Response:
HTTP/1.1 200
Content-Type: [application/json]
{
"firstName": {
"cursor": 9
},
"lastName": {
"cursor": 9
},
"kycStatus": {
"cursor": 27
},
"address": {
"streetAddress": "3244 jackson street",
"city": "City",
"state": {
"cursor": 11
},
"zipcode": {
"cursor": 7
}
}
}

I noticed that your cursor values are actually the number of characters in your regex. So that told me something was definitely wrong. I've never ran into this before.
I think you need to wrap your regex with value()
request {
method GET()
url value(consumer(regex('/v2/accounts/[0-9]+')))
}
response {
status 200
headers {
contentType(applicationJson())
}
body (
"firstName": value(producer(regex('[a-zA-Z]*'))),
"lastName": value(producer(regex('[a-zA-Z]*'))),
"kycStatus": value(producer(regex('FAILED|PASSED|PENDING|ERROR'))),
"address": [
"streetAddress" : "3244 jackson street",
"city" : "City",
"state" : value(producer(regex('[a-zA-Z]{2}'))),
"zipcode": value(producer(regex('^\\d{5}\$')))
]
)
}

I came across another example that affects request payloads in the same way, when generating wiremock stubs.
If I do not add at least one "field" to the request body, for example:
request{
// ...
body (
value(consumer(regex("[a-zA-Z0-9]+")), producer("derp"))
)
}
the request payload is required to be
{
"cursor" : 12
}
as seen by this wiremock stub generated in target/META-INF/.../mappings/myContract.json
"bodyPatterns" : [ {
"equalToJson" : "{\"cursor\":12}",
"ignoreArrayOrder" : false,
"ignoreExtraElements" : false
} ]
Solution
All I needed to do was add at least one field to the request body
body (
aMadeUpField: value(consumer(regex("[a-zA-Z0-9]+")), producer("derp"))
)
And the regex will now work for that field, as seen by my regenerated wiremock stub
"bodyPatterns" : [ {
"matchesJsonPath" : "$[?(#.['aMadeUpField'] =~ /[a-zA-Z0-9]+/)]"
} ]
This is probably why there is a line hidden in the documentation saying only JSON is supported for the request body.
Edit: Another thing to check is "anyBoolean()" which should be changed to "aBoolean()" and "anInteger()" which should be "anyInteger()" (SCC is i guess really inconsistent with naming...). I double check if they are right in IntelliJ by ctrl + hovering over the groovy methods and making sure they return DslProperty or ClientDslProperty
And, as the other poster said, be sure to wrap any regex() with value() and play around with consumer() and producer() if needed.

Related

Creatives LinkedIn API - Projection parameters not supported with new versioned API

`Hi All,
After LinkedIn API versioning, it seems that below projection parameter is not supported with creatives API call now :
com.linkedin.ads.SponsoredVideoCreativeVariables
com.linkedin.ads.SponsoredUpdateCarouselCreativeVariables
com.linkedin.ads.SpotlightCreativeVariablesV2
com.linkedin.ads.SponsoredUpdateCreativeVariables
com.linkedin.ads.JobsCreativeVariablesV2
com.linkedin.ads.SponsoredInMailCreativeVariables
Due to this, we are not able to fetch response similar to Old API call with new API now. This seems to be big impact to us.
For example , We are not receiving any of fields like 'showMemberProfilePhoto', 'forumName' for SpotlightCreativeVariablesV2 with new API which we used to get previously like mentioned below.
We have 2 headers in request as mentioned in LinkedIn API migration document.
X-Restli-Protocol-Version : 2.0.0
LinkedIn-Version : 202210
Old API call : https://api.linkedin.com/v2/adCreativesV2?ids=List({$creative_id})&projection=(results(*(variables(*,data(*,com.linkedin.ads.SpotlightCreativeVariablesV2(*,share~(*)))))))
Old API Response :
{
"results": {
"46524875": {
"variables": {
"clickUri": "$clickUri",
"data": {
"com.linkedin.ads.SpotlightCreativeVariablesV2": {
"showMemberProfilePhoto": true,
"forumName": "$forumName",
"description": "$description",
"logo": "$logo",
"headline": "$headline",
"callToAction": "$callToAction"
}
}
}
}
}
}
New API Call : https://api.linkedin.com/rest/creatives?ids=List(urn%3Ali%3AsponsoredCreative%3A{$creative_id})
New API Response :
{
"results": {
"urn:li:sponsoredCreative:$creative_id": {
"servingHoldReasons": ["$servingHoldReasons"],
"lastModifiedAt": 12345678000,
"lastModifiedBy": "",
"content": {
"reference": "urn:li:ugcPost:$ugc_post"
},
"createdAt": 1234562340000,
"isTest": false,
"createdBy": "$createdBy",
"review": {
"status": "APPROVED"
},
"isServing": false,
"campaign": "urn:li:sponsoredCampaign:$campaign_id",
"id": "urn:li:sponsoredCreative:$creative_id",
"intendedStatus": "ACTIVE",
"account": "urn:li:sponsoredAccount:$account_id"
}
},
"statuses": {
"urn:li:sponsoredCreative:creative_id": 200
},
"errors": {}
}
Is there any way to get all those fields we used to get in old API call with new API as we need these fields for processing.
`

Media type ignored in open api response

I'm trying to include a bad request (400) response schemas in the open api document for the web api I'm building in .NET 6. The problem is, the media type always defaults to application/octet-stream even though I explicitly set it to application/json.
My controller is decorated with the following attribute:
[ProducesResponseType((int)HttpStatusCode.OK)]
[ProducesResponseType(typeof(BadRequestResult), (int)HttpStatusCode.BadRequest, "application/json")]
But, the media type for the response 400 is incorrect in the generated open api document:
"200": {
"description": "",
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/Foo"
}
}
}
},
"400": {
"description": "",
"content": {
"application/octet-stream": {
"schema": {
"type": "string",
"format": "binary"
}
}
}
}
Am I missing something or is this a bug in NSwag?
So this is no bug, I was using ObjectResult as the response type instead of ProblemDetails. Apparently this class could not be serialized or something and that produced a different response media type.
So no bug!

Dialogflow simulator not responding

I am testing a simple conversation from my dialogflow simulator using a fulfillment hosted in firebase functions.
And I am receiving the fulfillment response when triggered
But my simulator is showing this. Saying no response is received.
Please help
The complete RAW fulfillment response
{
"responseId": "99b660de-e2ca-4d8c-ace5-ef724fe5ee72",
"queryResult": {
"queryText": "male",
"parameters": {
"gender": "male"
},
"allRequiredParamsPresent": true,
"webhookPayload": {
"google": {
"richResponse": {
"items": [
{
"simpleResponse": {
"textToSpeech": "Amazing"
}
}
]
},
"expectUserResponse": true,
"userStorage": "{\"data\":{}}"
}
},
"outputContexts": [
{
"name": "projects/assurance-purple/agent/sessions/bf891cbe-8642-eb61-ed7b-d6796adfab60/contexts/_actions_on_google",
"lifespanCount": 99,
"parameters": {
"data": "{}",
"gender.original": "male",
"gender": "male"
}
}
],
"intent": {
"name": "projects/assurance-purple/agent/intents/96b523a0-7a3a-4135-bdfc-d9d8ad16b661",
"displayName": "getGender"
},
"intentDetectionConfidence": 1,
"diagnosticInfo": {
"webhook_latency_ms": 45
},
"languageCode": "en"
},
"webhookStatus": {
"message": "Webhook execution successful"
}
}
My actions on google Testing debug tab
`
{
"response": "We're sorry, but something went wrong. Please try again.",
"expectUserResponse": false,
"conversationToken": "",
"audioResponse": "",
"visualResponse": {
"visualElementsList": [
{
"displayText": {
"content": "Sorry, this action is not available in simulation"
}
}
],
"suggestionsList": [],
"agentLogoUrl": ""
},
"clientError": 4,
"is3pResponse": false
}
`
You don't show the entire response (copying and pasting it as text in your question would have been better), but it looks like you're sending a response back for an Action, but trying to test it in Dialogflow's conversation tool.
The Actions on Google response is slightly different than the response that Dialogflow expects to handle the additional features that the Assistant supports. Because of this, you need to use the Actions on Google simulator when testing your agent.
The Dialogflow test is looking for some specific fields to show the response that are not included with the actions-on-google library, and it will not show anything that is in a Google RichResponse object.
To summarize:
If you are working with an Action, use the Actions on Google simulator.
If you are working with other Dialogflow integrations, you can use the test tool on the right in Dialogflow.
Update
The error you're indicating from the AoG Simulator suggests that you're trying to just issue a statement in the conversation and not starting the Action, or that the Action has quit. Make sure you're talking to the action by starting it with "talk to my test app" or whatever the name of your Action is.

Why assert in #PactVerification?

I don't understand the use of assert in #PactVerification. To me it seams more like a complicated way of saying 1 == 1. For example:
import static org.assertj.core.api.Assertions.assertThat;
public class PactConsumerDrivenContractUnitTest {
#Rule
public PactProviderRuleMk2 mockProvider
= new PactProviderRuleMk2("test_provider", "localhost", 8080, this);
#Pact(consumer = "test_consumer")
public RequestResponsePact createPact(PactDslWithProvider builder) {
return builder
.given("test GET ")
.uponReceiving("GET REQUEST")
.path("/")
.method("GET")
.willRespondWith()
.body("{\"condition\": true, \"name\": \"tom\"}")
}
#Test
#PactVerification()
public void givenGet_whenSendRequest_shouldReturn200WithProperHeaderAndBody() {
//when
ResponseEntity<String> response
= new RestTemplate().getForEntity(mockProvider.getUrl(), String.class);
//then
assertThat(response.getBody()).contains("condition", "true", "name", "tom");
}
}
So first in "createPact" we state
body("{\"condition\": true, \"name\": \"tom\"}")
Then in givenGet_whenSendRequest_shouldReturn200WithProperHeaderAndBody annotated #PactVerification we do this
assertThat(response.getBody()).contains("condition", "true", "name", "tom");
But why? We just said that! As far as I can see the assertion does not show up in the generated Pact file. It seams to fill no purpose?
In addition to that, I thought that the idea of contract testing was to reduce the need for integration test since they can break for example if test data changes. But here we still depend on test data. If there are no "Tom" in the Provider, then the test will fail. I primarily wanted to test if the contract is broken, not if the test data has changed.
The example given is a contrived one. In real life using Pact, you wouldn't do this. Your PactVerification would invoke a collaboration method/class/thing which is responsible for the external call to the service you are mocking.
So your assertions are then on what the collaborating function is doing.
Eg. A User Service might create an object with certain properties, that you know only are populated by that external call.
Testing assertions in your #PactVerification test method is not mandatory, yet still it might be very helpful. E.g. you may make a typo in your JSON body string and you wont be able to catch it in your test and it will break provider's pipeline. Assertions in this case have nothing to do with generated Pact file, they play role of a guard that checks in the end if the contract you have just defined (RequestResponsePact) matches all your expectations (assertions).
Also it is worth mentioning that your consumer contract tests should break only if provider tries to release a change that makes your expectations broken. And this is consumer's responsibility to write good contract tests. In your example you have defined following expectation:
#Pact(consumer = "test_consumer")
public RequestResponsePact createPact(PactDslWithProvider builder) {
return builder
.given("test GET ")
.uponReceiving("GET REQUEST")
.path("/")
.method("GET")
.willRespondWith()
.body("{\"condition\": true, \"name\": \"tom\"}")
}
This contract will be satisfied as long as condition == true and name == tom. This is over-specification of a response. You could define more flexible response with PactDslJsonBody DSL instead:
#Pact(consumer = "test_consumer")
public RequestResponsePact createPact(PactDslWithProvider builder) {
final DslPart body = new PactDslJsonBody()
.stringType("name", "tom")
.booleanType("condition", true);
return builder
.given("test GET ")
.uponReceiving("GET REQUEST")
.path("/")
.method("GET")
.willRespondWith()
.body(body)
.toPact();
}
This fragment will generate Pact file like:
{
"provider": {
"name": "providerA"
},
"consumer": {
"name": "test_consumer"
},
"interactions": [
{
"description": "GET REQUEST",
"request": {
"method": "GET",
"path": "/"
},
"response": {
"status": 200,
"headers": {
"Content-Type": "application/json; charset=UTF-8"
},
"body": {
"condition": true,
"name": "tom"
},
"matchingRules": {
"body": {
"$.name": {
"matchers": [
{
"match": "type"
}
],
"combine": "AND"
},
"$.condition": {
"matchers": [
{
"match": "type"
}
],
"combine": "AND"
}
}
}
},
"providerStates": [
{
"name": "test GET "
}
]
}
],
"metadata": {
"pact-specification": {
"version": "3.0.0"
},
"pact-jvm": {
"version": "3.5.10"
}
}
}
The main difference is that this Pact file uses matchingRules to test if:
type of condition field is boolean
type of name field is String
For strings you can also use PactDslJsonBody.stringMatcher(name, regex, value) method if needed. It allows you to define regular expression that will be tested using current field value.

Limit depth of data returned

Is it possible to limit the depth of data returned from Firebase database?
For example, if I want to get some data from a parent object without waiting for all of its children & sub-children, can I specify that I only want x levels of objects?
Firebase does not yet have this capability.
We do intend to add it, but don't have a timetable yet.
There appears to be a shallow option...
{
"message": {
"user": {
"name": "Chris"
},
"body": "Hello!"
}
}
// A request to /message.json?shallow=true
// would return the following:
{
"user": true,
"body": true
}
// A request to /message/body.json?shallow=true
// would simply return:
"Hello!"
From: https://firebase.google.com/docs/database/rest/retrieve-data

Resources