Also, standard question - are you using the latest version?

We then added 4 more from her machine, pushed them up, I pulled them, and there were 0 seen total once I started my server back up

I’m using

3.0.0

(downloaded on Friday last week)

Maybe it’s worth noting that with each new instance start, we get a

NeverStarted

status back from

recordings/status

even though we’ve previously recorded (on a different instance start). I figure that’s expected, but wanted to call it out in case it’s not!

I did notice that I’m not seeing a

__files

directory Edit: I do see one now that I started the instance again, but it’s empty even after shutting down.

mappings/

is still non-empty though.

Our file structure is like

wiremock/
wiremock/jar
wiremock/mappings/
wiremock/__files/

So the jar itself is a sibling to

mappings/

and

__files

I did try doing something like:

wiremock/standalone.jar
wiremock/root/
wiremock/root/mappings
wiremock/root/__files

and passing

root

as

root-dir

, but no luck there either. I tested that because I noticed the restrictions around loading resources from root of the classpath when trying to bundle stubs with the jar, so figured maybe the mappings and stuff couldn’t be a sibling of the jar itself

Recorded on my machine, then my coworker started the server and tried to hit the server and got a `404`:

A few tips for repro (since I assume you’ll do something like

curl

or similar and not run the Flutter app): 1. The jar and

mappings

are in

server/

directory 2. We’re running on port

57247

3. The endpoint that has a recording is

<http://localhost:57247/todos/1>

(which is what the app is hitting when you tap the button)

This is just using https://jsonplaceholder.typicode.com/ for the proxied URL

Recording was started with the

POST

request I mentioned earlier and the following body:

{
  "targetBaseUrl": "<https://jsonplaceholder.typicode.com>",
  "captureHeaders": {
    "maestro-test-id": {}
  },
  "persist": true
}

That

captureHeaders

block is being used in our app but is not technically needed for the repro app. I just left it there in case it matters.

Coworker’s terminal/server output:

I see the issue - the mapping file has lost its .json extension somehow. WireMock only scans .json files from that folder, so it’s ignoring the one that’s there.

Could this have happened when you copied the files, or did the recorder produce that? If the latter we have a bug on our hands…

I just started the server, recorded, stopped, and then pushed it all up

(just tested again with same result)

Great catch though 😄

Confirmed that a simple

mv todos_1-4d6cf6d4-9172-4027-b00d-5673e990b0e1 todos_1-4d6cf6d4-9172-4027-b00d-5673e990b0e1.json

fixes the issue!

Do you want me to open a Github issue in case others run into this, and so it can be tracked/a PR opened against it?

(ducking out for dinner with the family, but I’m happy to help create the issue if desired. really appreciate your help here @Tom!!)

Especially considering your local time. Above and beyond the call of duty for real!