Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Enable executor recording mode (#1997)
# Description This PR is focused on enabling the recording injection mode for CI/tests in the execution environment. The recording mode provides a mechanism to record and replay end-to-end tests, enhancing the reliability and efficiency of our testing process. For detailed information on the recording mode, please refer to our [documentation](https://github.com/microsoft/promptflow/blob/main/docs/dev/replay-e2e-test.md). In this PR, we still keep the connection configuration in CI to make sure backward compatibilities. Meanwhile, enable the recording injection fixture to switch test into recording mode. ## **Key Features of This PR:** ### **Generation of Test Records** The generation of records for execution tests when they are missing in the shelve database, to make it work under recording mode. ### **Multi-Process Compatibility** Resolves issues related to the recording injection mode in a multi-process environment, particularly with processes spawned/forkserver. **_What is the issue under multi/new Process(spawn/forkserver)?_** Spawn/forkserver mode will not replicate the resources/setups from main Process, including the recording setup. This would make the recording not working anymore. ![image](https://github.com/microsoft/promptflow/assets/95913588/4cc8f68a-f61f-49ad-b2bd-6717f4d304bf) **_How you resolved this issue?_** There are multiple ways to pass the recording setup in new Process, like environment variable, serializable object as argument etc. But these might incur interface change or too complex to squeeze into simple state object. We choose to re-import the state into new Process. 1) Create new target method for Process: this new target is used to re-import the state needed Example: For new Process target method _process_wrapper, for define another wrapper method outside and inject the recording state ![image](https://github.com/microsoft/promptflow/assets/95913588/426827a0-3c1e-426d-864f-ec85ad611416) 2) Define a customized Process class with above new targets Enable this new target method whenever new Process spawned/forkservered ![image](https://github.com/microsoft/promptflow/assets/95913588/21756ecf-fbed-4d6e-a21a-79228988b407) 3) Override context.Process or multiprocess.Process class multiprocessing.get_context("spawn").Process = MockSpawnProcess or multiprocessing.Process = MockSpawnProcess We have implemented above logic in codes and integrated as part of recording injection fixture for testing. **_So all the tests under executor/sdk would intercept the third-party call like this as default in CI?_** Yes, all the CI is enable with "PROMPT_FLOW_TEST_MODE=replay". All the openai/aoai related calls would be mocked to do recording result retrieval rather than real api request. **_Sometimes we might have necessity to customize the openai/AOAI call in tests. How shall we do instead of using the default recording mock?_** Yes, 1) Create your own target with customized mocking about openai/aoai call . 2) Override the default recording target via context manager "override_process_target" Sample Tests: test_executor_openai_telemetry **_In which scope the recording mode is enabled?_** The recording mode is enabled per requiriment. If the test are involved with 3rd party service with connection, like openai/aoai etc, it is required to enable recording mode. If not, your PR will fail at the CI tests since the connections info are not configured. To enable recording mode, just make sure the fixture "recording_injection" is required in your test class level or method level. _**Why not make recording mode a session-level fixture or required fixture for all tests?**_ 1) recording setup is complicated. it might introduce expected behavior if abuse 2) Some tests like **test_executor_openai_telemetry** might server some special test purpose. If enable recording, the customized mocking might be not easy to be configured. **_Note:_** _Above logic resolved this issue for one layer of new Processing. If you have nested new Processing action , you need to repeat above logic at each layer._ ## **Todos and Ongoing Work[updated]:** ### **[Done]Metrics Mocks** Currently, this openai_injector is skipped as it does not involve actual openai/aoai requests. This omission leads to potential inaccuracies in metrics calculation, especially token usage, in recording mode. Future work will focus on integrating openai_injector.py into the recording mode. --- this fixed already by [[fundamental] Recording support metrics by crazygao · Pull Request #1762 · microsoft/promptflow (github.com)](#1762) ### **[Todo]Consolidation of Configuration** Efforts are underway to consolidate the configuration settings for recording injection in both the execution environment and the SDK, aiming for a more unified and streamlined setup. ### **[Done]Record error info** Record not only regular tool execution result, but also error response if exception ocurr ----- have fixed this in this PR, sample tests: test_executor_node_overrides ### **[Done]Test langchain** Support langchain test with agent ---- fixed by [[fundamental] Recording support metrics by crazygao · Pull Request #1762 · microsoft/promptflow (github.com)](#1762) ### **[Todo] Create pipeline CI without connection to monitor** We need to CI without connection to identify tests which needs the record setup. ### **[Todo] Make migration plan to make the non-connection CI as main CI** Need to make plan to safely switch to new record mode. Make sure there are fallback logic if record has flow design which might hinder the new feature delivery. ### **[Todo] Enable more apis with recording mode** like assistant apis & tests # All Promptflow Contribution checklist: - [x] **The pull request does not introduce [breaking changes].** - [ ] **CHANGELOG is updated for new features, bug fixes or other significant changes.** - [x] **I have read the [contribution guidelines](../CONTRIBUTING.md).** - [x] **Create an issue and link to the pull request to get dedicated review from promptflow team. Learn more: [suggested workflow](../CONTRIBUTING.md#suggested-workflow).** ## General Guidelines and Best Practices - [x] Title of the pull request is clear and informative. - [ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, [see this page](https://github.com/Azure/azure-powershell/blob/master/documentation/development-docs/cleaning-up-commits.md). ### Testing Guidelines - [x] Pull request includes test coverage for the included changes. --------- Co-authored-by: Philip Gao <[email protected]> Co-authored-by: chjinche <[email protected]> Co-authored-by: Cheng Liu <[email protected]> Co-authored-by: Han Wang <[email protected]> Co-authored-by: chenslucky <[email protected]> Co-authored-by: cs_lucky <[email protected]> Co-authored-by: Ying Chen <[email protected]> Co-authored-by: Ying Chen <[email protected]> Co-authored-by: chenyang <[email protected]> Co-authored-by: Peiwen Gao <[email protected]>
- Loading branch information