test(flagd): drop the per-scenario /stop in e2e teardown once the testbed includes flagd-testbed#396
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
Research direction
Start at providers/flagd/src/test/java/.../e2e/steps/ProviderSteps.java and read ProviderSteps.tearDown to find the /stop POST block, plus ContainerPool.release and the NoOp provider swap that must stay. First confirm the flagd-testbed dependency has been bumped to a release containing open-feature/flagd-testbed#396 (check the testbed version in the flagd provider's build files), since removing /stop before that gains nothing. Done means the /stop block is gone from tearDown while ContainerPool.release and the provider swap remain, and the full e2e suite (in-process, RPC, file providers) still passes.
Written by the indexing model from the issue text.
Description
Problem
ProviderSteps.tearDown (providers/flagd/src/test/java/.../e2e/steps/ProviderSteps.java) POSTs /stop to the launchpad after every scenario. That makes every /start a cold flagd start.
open-feature/flagd-testbed#396 makes /start reuse the running flagd and restore the baseline flag state in place. Isolation no longer needs the /stop, and keeping it means the suite never gets the speedup.
Proposal
After bumping the testbed to a release that includes open-feature/flagd-testbed#396, remove the /stop block from tearDown. Keep ContainerPool.release and the NoOp provider swap.
Evidence
Tested locally with the /stop removed, against an image built from flagd-testbed#396 and one built from testbed main. All 590 tests (in-process 224, RPC 214, file 152) passed in every run. Wall time (in-process / RPC / file):
with /stop |
without /stop |
|
|---|---|---|
| flagd-testbed#396 | 102-107s / 73-79s / 48-65s | 96s / 66s / 41s |
| testbed main | 100s / 75s / 50s | 120s / 79s / 49s |
The machine was shared with other test runs, so treat the times as indicative. Without flagd-testbed#396, dropping /stop gains nothing, which is why this should wait for the bump.
- Dominant language
- Java
- Stars
- 50
- Forks
- 87
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 53
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from open-feature/java-sdk-contrib
-
Bug: FlagStore does not interrupt watcher thread on shutdownPossibly taken @lbarrosby claimed this 2 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
open-feature/java-sdk-contrib#1966 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
open-feature/java-sdk-contrib#1861 ·
Maintainers usually reply within 1 day
-
fix!: opentelemetry-semconv-incubating bump renames feature_flag.provider_name attributePossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
open-feature/java-sdk-contrib#1843 ·
Maintainers usually reply within 1 day
-
[ConfigCat] Evaluation errors are returned as a successful default with no error codePossibly taken @RaphaelFakhri claimed this 3 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 68/100
open-feature/java-sdk-contrib#1963 ·
Maintainers usually reply within 1 day
-
[go-feature-flag] Should remote evaluation emit events and fail init on an unreachable relay proxy?Possibly taken @thomaspoignant claimed this 17 days ago. Open
open-feature/java-sdk-contrib#1948 · 1 comment · 1 assignee ·
Maintainers usually reply within 1 day
All issues in open-feature/java-sdk-contrib
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
NationalSecurityAgency/ghidra#10149 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
yegor256/antlr2ebnf-maven-plugin#155 ·
Maintainers usually reply within 1 day
-
account bug exercise lecture programming user interface
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ls1intum/Artemis#14512 · 1 comment ·
Maintainers usually reply within 1 day
-
kind:bug priority:major
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
swiftlang/swift-java#955 ·
Maintainers usually reply within 1 day