Hi team, a question about 'dynamic state', the official doc says best effort support on storing the state values:

State values are ephemeral; they are stored in a Least Recently Used cache, and whilst WireMock Cloud makes a best effort attempt to maintain them no guarantee is made about their survival.

In order to prevent resource exhaustion we apply some limits.

Any state value cannot exceed 100,000 characters.

On Enterprise plans, up to 100,000 values can be defined before the least recently used values start being ejected from the store.

On other plans with Dynamic State enabled only 100 values are maintained in the store.

Could you please confirm if this means that as long as each individual value is under 100,000 characters and the total number of values stays within the specified limit, the persistence of state values is guaranteed by the LRU cache? Additionally, is there an expiration time for these values? If the LRU storage is part of the same service as the code logic, could the values be removed during a service rollout? And I tried with my account ( I though it was supposed to be enterprise plan) , it seems the values count will be no more than 2040, is that another restriction?

State is intended to be short term, and you’re correct that it’s cache-like, so removed when there’s a deployment. Please can you share the steps you took when hitting the 2040 limit, and also which mock API (domain name) this was in?

Thank you for the explanation, Tom! It helped a lot. Regarding the 2040 limit, this is the api to retrieve all items:

curl --location '<https://basketdemo1.wiremockapi.cloud/baskets/11/items>'

And following is the add item api to the existing basket:

curl --location '<https://basketdemo1.wiremockapi.cloud/baskets/11/items>' \
--header 'Content-Type: application/json' \
--data '{
    "id": "20001",
    "item": "name-20001",
    "quantity": 20001
}'

step 1: 1. call the first api, there were 2040 items returned in total 2. call the second api, it will return 200, which indicates that item is added to the list 3. call the first api again, there was supposed to be 2041 items including the latest added one, but there was not a note here is that this second API works well for the items added when the total number is less than 2040 , after the total number exceeds 2040, seems it is not able to expand anymore.

For this API the single item size limit is the where the issue is, since it’s adding items to a single JSON array. This request log shows that it failed to add the 2041st one (although it returning 200 isn’t great and we’ll look into that). Since you’re on an Enterprise plan we should be able to raise this limit for you, let me check.

Hi @Tom, actually I'm in a trial investigation about the upper bound of this amount limit, I think the 100,000 is enough, while the data persistency is something I care a lot, because we want to use wiremock to statically store some mock cases which could be reused for a pretty long time. So regarding the data persistency, do you think there is some extension or workaround on the wiremock cloud solution to achieve that?

I would suggest for long-lived behaviour/data you should either build it directly into your stubs or use data sources. We recommend that when using the state feature, that you always have a “base state” defined by your stubs that is valid even if your state store is completely empty. Then as state gets added it’s effectively layered on top of this base state in order to represent points in a flow e.g. states a payment might go through towards completion.

Hi @Tom , that would be helpful. The scenario is that we want to maintain a pool of mock records, each record is tagged for a business scenario, like the mock record of 'the verification pass result', 'the verification failed due to low image quality', there might be hundreds of categories with corresponding response, the response are different in some fields. On the one hand, the mock records could be maintained so they need to be added via POST API, and retrieved via GET API, where 'dynamic state' really suits; On the other hand, we want to these cases is long-lived, because they are always valid so they could be reused not across multiple API calls.

It sounds like the best approach would be to define a set of distinct stubs for each business scenario, relying on differing request values to match different responses. Then in some cases (probably just the happy paths) you could add some state on top to accurately simulate cases where data is created/updated.

Trying to understand that, pre-define a set of distinct stubs for the constant cases, as for the flexible ones, we could use the state feature to add or remove, but that's only for temporary usage, maybe one-time. Is that correct?

Yes, stubs are persistent

It sounds like a nice idea! One more question, may I know if there is API to automatically add one stub?

Yes, we've just published a new API docs site that shows how to do this: https://docs.wiremock.io/api-reference/stub-mappings/create-a-new-stub-mapping

Awesome ! When trying to use that API, I have another two questions: 1. what should the username & password be like in the authorization header, asking this because I'm using the okta login mode 2. I sent the following request and got HTTP 201 code response, but when checking the wiremock console the API is not created as expected:

curl --location '<https://wmc.wiremockapi.cloud/v1/mock-apis/6rk71/mappings>' \
--header 'Content-Type: application/json' \
--data '{
  "request": {
    "method": "GET",
    "url": "/some/thing"
  },
  "response": {
    "body": "Hello world!",
    "headers": {
      "Content-Type": "text/plain"
    },
    "status": 200
  }
}'

You should pass

Authorization: Token <api_token>

as the header. You can find your token here: https://app.wiremock.cloud/account/security

Actually it’s that the domain name in that curl request is for the mock of WireMock’s API

So:

curl --location '<https://api.wiremockapi.cloud/v1/mock-apis/6rk71/mappings>' \
--header 'Authorization: Token <api_token>' \
--header 'Content-Type: application/json' \
--data '{
  "request": {
    "method": "GET",
    "url": "/some/thing"
  },
  "response": {
    "body": "Hello world!",
    "headers": {
      "Content-Type": "text/plain"
    },
    "status": 200
  }
}'