[#107] Honoured feature-level tags when starting and stopping the server. - #128
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 6 minutes Limit details: You’ve used all 2 included reviews currently available under your plan. You completed 87 included PR reviews in the past 7 days; at that activity level, included reviews refill at 2 reviews per hour. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Comment |
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #128 +/- ##
==========================================
+ Coverage 84.98% 85.02% +0.03%
==========================================
Files 3 3
Lines 433 434 +1
==========================================
+ Hits 368 369 +1
Misses 65 65 ☔ View full report in Codecov by Harness. |
Closes #107
Summary
PhpServerContextgated its@beforeScenarioand@afterScenariohooks on$scope->getScenario()->hasTag(static::TAG), butScenarioNode::getTags()only returns tags attached directly to the scenario node, not tags inherited from the enclosing feature, so a feature tagged once at the top silently disabled both hooks for every scenario in it. This was reproducible in this repo:tests/behat/features/apiserver.featuretags@apiserverat feature level, so across all 14 scenarios the hooks touched port 8888 (PhpServerContext) only, port 8889 (ApiServerContext) was never started or stopped by the hooks, and the whole suite performed exactly 1 process termination; the API scenarios still passed only becauseapiIsRunning()lazily callsstart(), which masked the problem, and the server was never stopped by the hook, leaking until the next run'sstart()reclaimed the port. The fix adds a sharedisTagged(ScenarioScope $scope)helper that checks both$scope->getScenario()->hasTag()and$scope->getFeature()->hasTag(), sinceScenarioScope, the interface bothBeforeScenarioScopeandAfterScenarioScopeextend, exposes bothgetFeature()andgetScenario(), andFeatureNodeuses the sameTaggedNodeTraitasScenarioNodeso it answershasTag()the same way.ApiServerContextextendsPhpServerContextand inherits both hooks unchanged, so fixing the base class restores correct behaviour for both contexts. After the change, on the same suite, port 8889 goes from 0 hook interactions to 26 (13 scenarios times start and stop) and process terminations go from 1 to 14, with all 14 scenarios and 153 steps still passing. As a side benefit,start()passes a freshPROCESS_TIMESTAMPeach time and the API server keys its state file on that value, so where one server instance and one state file used to span all 13 API scenarios, each scenario now gets its own, making cross-scenario state isolation stronger than before.Changes
isTagged(ScenarioScope $scope)toPhpServerContext, checking both the scenario's and the feature's tags viahasTag().beforeScenarioStartServer()andafterScenarioStopServer()to callisTagged($scope)instead of checking$scope->getScenario()->hasTag()directly.testIsTagged()toPhpServerContextTestwith a 5-case data provider: tagged on the scenario, tagged on the feature, tagged on both, tagged on neither, and carrying only a different server's tag. Verified the test catches the bug: with the feature-tag half of the condition removed, exactly 1 case fails (tagged on the feature) and the other 4 pass.Before / After