Environment variables from per-lambda config doesn't correctly update environment across tests
- Dominant language
- Python
- Stars
- 11.1k
- Forks
- 1k
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 2
Description
We've been experimenting with chalice and generally have been pretty pleased, but we've run into an issue while writing tests with `pytest`.
Our chalice app contains multiple lambda functions with per-lambda environment variables:
```json
{
"version": "2.0",
"app_name": "my-app",
"stages": {
"dev": {
"lambda_functions": {
"func1": {
"environment_variables": {
"var1": "something",
"var2": "something else",
}
},
"func2": {
"environment_variables": {
"env1": "example",
"env2": "other example"
}
}
}
}
}
}
```
With our tests, we use a fixture for handling creating/tearing down a test client:
```python
@pytest.fixture
def client() -> Client:
with Client(app) as test_client:
yield test_client
```
Which theoretically should configure the environment variables defined in the config file when we call `invoke`.
What seems to be happening is that if we run our lambda function tests individually, the correct environment variables seem to be assigned, but if we run both of our lambda function tests in the same test session, only the first set of environment variables are configured (from the test that was invoked first) in _both_.
I haven't quite figured out if something is not being reset properly between tests, or if there's a bug in setting up the environment from the config in the case of per-lambda environment variables with the test client.
The issue is resolved if we monkeypatch the environment with the necessary variables.
Contributor guide
Research direction
Reproduce the issue with the pytest client fixture and two lambda functions invoked in one test session, then compare the environment seen by each function. Trace the test client's environment setup and teardown to find where per-lambda values persist between invocations. Done means each function receives its own configured variables when both tests run together, without monkeypatching.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, python
- Domain
- backend, cloud
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100