llama-stack-mirror/tests/integration/recordings/responses/a5187d9d5057.json
Ashwin Bharambe c3d3a0b833
Some checks failed
Integration Auth Tests / test-matrix (oauth2_token) (push) Failing after 1s
Test External Providers Installed via Module / test-external-providers-from-module (venv) (push) Has been skipped
Integration Tests (Replay) / Integration Tests (, , , client=, vision=) (push) Failing after 3s
SqlStore Integration Tests / test-postgres (3.12) (push) Failing after 4s
SqlStore Integration Tests / test-postgres (3.13) (push) Failing after 7s
Update ReadTheDocs / update-readthedocs (push) Failing after 3s
Test External API and Providers / test-external (venv) (push) Failing after 5s
Vector IO Integration Tests / test-matrix (push) Failing after 7s
Python Package Build Test / build (3.13) (push) Failing after 8s
Python Package Build Test / build (3.12) (push) Failing after 8s
Unit Tests / unit-tests (3.13) (push) Failing after 14s
Unit Tests / unit-tests (3.12) (push) Failing after 14s
UI Tests / ui-tests (22) (push) Successful in 1m7s
Pre-commit / pre-commit (push) Successful in 2m34s
feat(tests): auto-merge all model list responses and unify recordings (#3320)
One needed to specify record-replay related environment variables for
running integration tests. We could not use defaults because integration
tests could be run against Ollama instances which could be running
different models. For example, text vs vision tests needed separate
instances of Ollama because a single instance typically cannot serve
both of these models if you assume the standard CI worker configuration
on Github. As a result, `client.list()` as returned by the Ollama client
would be different between these runs and we'd end up overwriting
responses.

This PR "solves" it by adding a small amount of complexity -- we store
model list responses specially, keyed by the hashes of the models they
return. At replay time, we merge all of them and pretend that we have
the union of all models available.

## Test Plan

Re-recorded all the tests using `scripts/integration-tests.sh
--inference-mode record`, including the vision tests.
2025-09-03 11:33:03 -07:00

56 lines
4 KiB
JSON

{
"request": {
"method": "POST",
"url": "http://0.0.0.0:11434/v1/v1/chat/completions",
"headers": {},
"body": {
"model": "llama3.2:3b-instruct-fp16",
"messages": [
{
"role": "user",
"content": "Test trace openai 1"
}
],
"stream": false
},
"endpoint": "/v1/chat/completions",
"model": "llama3.2:3b-instruct-fp16"
},
"response": {
"body": {
"__type__": "openai.types.chat.chat_completion.ChatCompletion",
"__data__": {
"id": "chatcmpl-376",
"choices": [
{
"finish_reason": "stop",
"index": 0,
"logprobs": null,
"message": {
"content": "I'll simulate a test for the LA-1030/5B linear accelerator, specifically for the H8 (High Voltage) model found in early models of the test rail. Note that this is not meant to be taken as actual test results but rather a demonstration.\n\n### Introduction:\nThe LA-1030/5B was used primarily for high-energy physics and nuclear research during the 1970s and 1980s. This linear accelerator was capable of producing proton beams with energies up to several GeV. The H8 model, also known as the 'High Voltage' component, is a series of power supplies that drive the high voltage DC (HV) accelerators.\n\n### Test Setup:\n\n- **Test Goal:** Measure the output of the LA-1030/5B H8 model linear accelerator and assess its ability to generate stable, high-voltage direct current (HVDC) to power it properly.\n \n - The setup consists of a single test rail containing one of these H8 modules. A precise DC voltage is supplied to the linear accelerator via an external DC source.\n\n### Operating Parameters:\n\n- **Input Voltage:** To ensure the linear accelerator operates within its safe operating parameters, input voltages will be varied from 20KV to 140KV.\n- **Current Delivery:** Monitoring current at these different output levels requires a precise multimeter or oscilloscope. \n- **Voltage Level and Current Stability:** The voltage should stabilize as close as possible to the desired output level.\n\n### Potential Issues\n\n1.) Over-Pressure in H8 Modules\n - During high voltage levels, there's a risk of over-pressurization in the component casing due to the vacuum properties within the modules.\n - Check for any external signs of stress or leakage.\n2.) Current Limitation and Arcing\n - High current requirements demand close monitoring of the accelerator components and associated connections.\n - An excessive arc can be detrimental to electronics connected to the system.\n3.) Interlocks and Safe Guards\n\n- **Ensure alignment:** Prevent accidental triggering.\n\n4.) Insulation integrity \n - Potential risks from faulty or non-insulated components\n\n### Results Analysis:\n\nBased on this hypothetical test, some potential results could include:\n1. Output voltage stability for the chosen input voltages\n2. Ability to exceed the accelerator's highest voltage ratings.\n3. Consistency between different current levels at various output voltage tests.\n\nThis exercise is a general simulation and might not reflect real-world conditions or performance specifications of an actual LA-1030/5B linear accelerator. The focus here was on demonstrating how one could analyze data from such a system, given typical components involved in linear accelerators at that time period.",
"refusal": null,
"role": "assistant",
"annotations": null,
"audio": null,
"function_call": null,
"tool_calls": null
}
}
],
"created": 1756921225,
"model": "llama3.2:3b-instruct-fp16",
"object": "chat.completion",
"service_tier": null,
"system_fingerprint": "fp_ollama",
"usage": {
"completion_tokens": 547,
"prompt_tokens": 31,
"total_tokens": 578,
"completion_tokens_details": null,
"prompt_tokens_details": null
}
}
},
"is_streaming": false
}
}