Because
- When setting up glean sdk on cirrus side, we set the maxEvents to 500,
which means it waits on the client side to gather all 500 events, and
once it gets 500 then it sends the batch of events. Implementing
applications should be able to adjust the value that works best for
them.
This commit
- Add the option to set no. of events to store in buffer through `.env`,
by default it uses `10` now
Fixes#9534
Because
- We are using Sentry for all the Cirrus implementing applications such
as Monitor, VPN, and so on...... Currently, it is hard to track where
the error is coming from until we see the issue in detail.
This commit
- Sentry supports the concept of environment, so in the same project you
can configure different environment
- By default, Sentry uses a `production` environment, so the default
value used in initialization is `production`
- Add support for using environment so that the `cirrus-stage` project
can have `monitor-stage` and `vpn-stage` and similarly `cirrus-prod` can
have `monitor-prod` and `vpn-prod` environments.
Note: Sentry
[environment](https://docs.sentry.io/product/sentry-basics/concepts/environments/)
selection also makes it easy to filter the issues, for example
Fixes#9999
Because
- We have a demo app that can test the integration end to end, it has
the frontend and backend.
- We could stand up the experimenter, launch the experiment or rollout,
and push to RS, Cirrus can sync to RS and then the frontend can send a
request to the backend and then backend can reach out to Cirrus and can
ask for the feature config
- When the backend receives the response, can send the response back to
the frontend
This commit
- Tests end-to-end integration between the experimenter, RS, Cirrus, and
Demo app
- Test both the experiment and rollout end to end
fixes#9387
* fix#7185 chore(project): update local dev authentication for Jetstream
* update env vars for integration; add troubleshooting tip
* add gcp project access info
Because
* With the settings we shipped, timeout=60s, refresh=30s, wait=45*2=90s, we expect that after two invocations of the celery task the experiment will be marked as timed out and 90s gives us that extra 30s to wait, but I've observed that since the timeout calculation is detached from the celery schedule, it may occur that on the second invocation it can be milliseconds below the timeout point and so it won't timeout until the third invocation, and since that's 90s which butts up right against the 90s the test waits it can randomly happen just after the test ends, I verified that the test did in fact end just before the experiment was marked as timed out
This commit
* Changes the integration test timing to timeout=40s, refresh=20s, wait=60*2=120s which should give enough time for three invocations of the task to occur
Because
* We've seen a lot of intermittent failures in circle complaining about COMPOSE_HTTP_TIMEOUT being too low
This commit
* Let's try increasing it and see if that helps
Because
* We should be able to decrease the celery task timeouts so speed up the integration tests
This commit
* Turns them down to 5s to update and 10s to timeout
Yashika Khurana
Jared Lockhart
Mathieu Leplatre
Mike Williams
Tif Tran
Benjamin Forehand Jr