https://linen.dev logo
Join Slack
Powered by
Hi there! SUPER novice question, but we’ve just st...
# help
b
Hi there! SUPER novice question, but we’ve just started using WireMock and the recording and playback on a single machine worked great out of the box. I wanted to test playback of my persisted mappings on a different machine, so I persisted the jar, mappings, and __files directory to VCS and a coworker pulled them down on her machine, ran the server the same way I did on mine, but there were 0 mappings (according to the admin API). We then finally figured out that each time you stop/start the instance, even on the same machine, the same thing happens (0 mappings seen even though there are mappings in 
mappings/
). Is this expected? Are we just making an incorrect assumption that a new instance should be able to pick up existing mappings?
t
Hi Brandon, how did you start and stop the recorder? And did the mappings and __files directories have anything in them after you stopped recording?
Also, standard question - are you using the latest version?
b
We’re starting it via Postman with a POST request to 
<http://localhost:57247/__admin/recordings/start>
with a body of:
Copy code
{
  "targetBaseUrl": "<https://our.domain>",
  "captureHeaders": {
    "test-id": {}
  },
  "persist": true
}
and stopping it via a 
POST
request to 
<http://localhost:57247/__admin/recordings/stop>
The mappings directory does have mappings in it (14 total)
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.
t
It looks like you’ve mostly got it working. One thing to note, the root directory is the parent of 
mappings
and 
__files
(which must be siblings of each other). If you don’t explicitly set this via 
root-dir
it’ll be whatever directory you ran the JAR file from.
b
Yep that all makes sense. We’ve tried with and without the 
root-dir
option, neither work 😞
Our file structure is like
Copy code
wiremock/
wiremock/jar
wiremock/mappings/
wiremock/__files/
t
BTW on and off Zoom calls at the moment, so replies might be patchy…
👍 1
b
So we’ve tried 
root-dir
with a fully qualified path and with relative (
.
) but when using the former, it actually creates directories corresponding to the fully qualified path from the directory where the jar is 🙃
t
If you cd into your 
wiremock
folder, then run: 
java -jar jar/wiremock-standalone-3.0.0.jar
does this still not work?
b
Sorry by 
jar
I meant that’s the actual standalane jar (not i directory)
So the jar itself is a sibling to 
mappings/
and 
__files
Screenshot 2023-09-06 at 14.14.40.png
I did try doing something like:
Copy code
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
t
What you’re doing should work absolutely fine, I can’t see anything obviously wrong. Would you be able to zip up the files and DM to me?
b
@Tom I was able to reproduce this outside our enterprise project, put up a repro here: https://github.com/btrautmann/wiremock-repro
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:
Copy code
{
  "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:
t
Let me take a look
🙌 1
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…
b
Yeah I didn’t to any manual copying
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!
t
No worries, and yes please to the GH issue!
👍 1
b
2 Views
Open in Slack
PreviousNext
Powered by