You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support replay mode with garbage collection (microsoft#845)
This change enables a new 'replay' mode option that replays requests from the trace database.
Changes include:
1. Refactor driver to consume sequences from different sources (with trace database another supported source of specific
sequences, similar to the existing smoke test mode)
2. Generate 'replay blocks' as part of payload rendering. Replay blocks contain dynamic objects, but do not support
custom payloads (this is future work).
3. Enables replay to be based on replay blocks
With this change, RESTler generates sequences from replay blocks if available,
or from raw request/responses (similar to the existing replay mode) when they are not available.
The current version of replay is based on the rendered data sent at the time of
original sequence rendering. This has several limitations, such as not being able to
garbage-collect resources or plugging in custom payloads.
In particular, when a bug is reproduced in RESTler today, the same replay mechanism is used, which
means that GC does not collect resources created while reproducing the bug. Moreover, re-running
the same sequence without GC will not work if the resource has not been deleted if a resource-generating
request has a unique ID parameter (e.g. PUT /resource/{resourceId}), causing false negative non-reproducible
bugs.
This change addresses this issue by implementing replay blocks-based replay, which is invoked when reproducing bugs.
Note: the existing replay based on .replay.txt files will also be able to use this new mechanism if a grammar is provided,
but this is not implemented as part of this change.
4. Added a setting to filter the origin during DB replay.
To only replay specific origins, add the following to the settings file:
"replay": {
"include_origins": ["main_driver", "InvalidValueChecker"]
}
Testing:
- manual testing of demo_server replay as follows:
1) Run 'test' task and generate trace database
>restler.exe test --grammar_file .\Compile\grammar.py --dictionary_file .\Compile\dict.json --host localhost --target_port 8888 --settings .\compile\engine_settings.json --no_ssl
Engine settings:
{
"use_trace_database": true,
"trace_database": {
"root_dir": "d:\\demo_server\\trace_databases",
},
}
2) Run 'replay' task from above trace database
>restler.exe replay --replay_log ./trace_data.ndjson --grammar_file .\Compile\grammar.py --dictionary_file .\Compile\dict.json --host localhost --target_port 8888 --settings .\compile\engine_settings.json --no_ssl
- updated unit tests
Copy file name to clipboardexpand all lines: docs/user-guide/Replay.md
+24-3
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,7 @@ Any resources that were created during the replay will NOT be automatically dele
28
28
unless the replaying sequence itself deletes the resource.
29
29
Any resources created should be removed manually.
30
30
31
-
## Replay log format
31
+
###Replay log format
32
32
33
33
The replay log is created anytime a new bug bucket is reported.
34
34
This replay log consists of the full sequence of requests that were sent to create the bug.
@@ -60,7 +60,7 @@ You may notice that content-length and user-agent are not included in the replay
60
60
These fields are populated automatically by RESTler when the request is sent to the server,
61
61
so they are not needed (and shouldn't exist) in the log.
62
62
63
-
## Using replay logs to send custom sequences
63
+
###Using replay logs to send custom sequences
64
64
While the main purpose of replay logs are to re-test bugs previously found,
65
65
it is also possible to use these files as a way to send custom sequences to RESTler, similar to how you may send a request through *curl* or *Postman*.
66
66
@@ -84,4 +84,25 @@ while max_async_wait_time will attempt to perform an asynchronous polling-wait b
84
84
with a maximum resource-creation-wait-time of the max_async_wait_time setting.
85
85
86
86
87
-
##
87
+
## Using the Trace Database
88
+
89
+
Previously executed RESTler sequences may be re-played by configuring a trace database to be written during `test` or `fuzz` tasks, then specifying it as the replay file for the `replay` task.
90
+
91
+
For example:
92
+
93
+
1. Generate the trace database by adding the following to the engine settings:
94
+
```json
95
+
{
96
+
"use_trace_database": true,
97
+
"trace_database": {
98
+
"root_dir": "/path/to/trace_databases",
99
+
},
100
+
}
101
+
```
102
+
103
+
2. Replay the same sequences of requests (in the same order) from the replay log. The below command specifies to run the RESTler `replay` task. The grammar, dictionary, and engine settings files must be specified to enable generating unique dynamic object names and garbage collection as in the original run (note: custom payloads from the specified dictionary will not currently be used for replay). If the grammar and dictionary are omitted, the replay will execute the same request text as sent
104
+
in the original run, and GC will not be triggered.
Copy file name to clipboardexpand all lines: docs/user-guide/SettingsFile.md
+15
Original file line number
Diff line number
Diff line change
@@ -385,6 +385,21 @@ Dictionary containing settings for the trace database.
385
385
386
386
`cleanup_time` float (default 10): The maximum amount of time, in seconds, to wait for the data serialization to be complete before exiting.
387
387
388
+
### replay: dict (default empty)
389
+
390
+
Dictionary containing replay settings.
391
+
392
+
`trace_database_file_path` str (default None): The path to the trace database from which to replay requests.
393
+
Overrides the value of `--replay_file` if specified on the command line.
394
+
395
+
`include_origins` list (default empty list=No filtering): When replaying requests from the trace database, specify a list of origin values to use. For example:
0 commit comments