src/Sylius/Behat/Client/ResponseCheckerInterface.php (1)

95-104: Adding methods to a public interface is a BC break — prefer a dedicated, optional interface.

The PR adds new methods (cleanErrors, getDebugErrors, and implicitly needed appendError) to ResponseCheckerInterface. Any custom implementation (common in plugins/suites) will break. To avoid BC breaks and keep ApiPlatformClient loosely coupled, introduce a small DebugErrorCollectorInterface and have ResponseChecker implement it; inject that into ApiPlatformClient and DebugContext instead of expanding ResponseCheckerInterface.

Proposed new interface (outside this file), and minimal wiring changes:

<?php
// src/Sylius/Behat/Client/DebugErrorCollectorInterface.php
declare(strict_types=1);

namespace Sylius\Behat\Client;

use Symfony\Component\HttpFoundation\Response;

/**
 * Narrow contract dedicated to debug error collection.
 */
interface DebugErrorCollectorInterface
{
    /** @return list<string> */
    public function getDebugErrors(): array;

    public function cleanErrors(): void;

    public function appendError(Response $response): self;
}

• Make ResponseChecker implement DebugErrorCollectorInterface.
• Type-hint DebugErrorCollectorInterface in ApiPlatformClient and DebugContext constructors.
• Keep ResponseCheckerInterface unchanged (remove cleanErrors/getDebugErrors from it) to preserve BC.
  Do you want me to prepare a full patch across the affected files?

src/Sylius/Behat/Resources/config/suites/api/addressing/managing_zones.yml (1)

24-24: Gate verbose debug output behind a profile or env var.

Continuous debug logs can bloat CI output. Consider enabling the context only under a “debug” Behat profile or via an env flag to keep default runs quiet.

src/Sylius/Behat/Resources/config/suites/api/product/managing_product_options.yml (1)

27-27: Keep context ordering consistent across suites.

Minor: in other suites debug appears near other API response/save contexts. Aligning order helps scanability during maintenance.

src/Sylius/Behat/Resources/config/suites/api/taxon/managing_taxons.yml (1)

28-28: Avoid duplicate/overlapping error prints.

If api.admin.response already logs failures, ensure DebugContext only prints aggregated details on non-2xx responses (and preferably only on scenario failure) to prevent noisy duplication.

src/Sylius/Behat/Resources/config/suites/api/product/managing_products.yml (1)

54-54: Makes sense to expose debug info in product management scenarios

Including the debug context in product admin API tests should speed up failure triage. Order within the contexts list is not critical for After* hooks, so placement here is acceptable.

If this context is now required across all API suites, consider centralizing it (e.g., a shared include or a base API suite template) to avoid future drift. I can propose a consolidation plan if helpful.

src/Sylius/Behat/Resources/config/suites/api/checkout/paying_for_order.yml (1)

48-48: Review DebugContext Registration Across Suites

The DebugContext correctly cleans up errors after each scenario (cleanErrors in afterScenario), preventing cross-scenario leakage. However, the debug context is registered in multiple related suites, which can lead to redundant output and noise.

Affected registrations:

• src/Sylius/Behat/Resources/config/suites/api/cart/shopping_cart.yml (line 30): - sylius.behat.context.api.debug
• src/Sylius/Behat/Resources/config/suites/api/cart/accessing_cart.yml (line 32): - sylius.behat.context.api.debug
• src/Sylius/Behat/Resources/config/suites/api/checkout/checkout.yml (line 57): - sylius.behat.context.api.debug
• src/Sylius/Behat/Resources/config/suites/api/checkout/paying_for_order.yml (line 48): - sylius.behat.context.api.debug

Recommendation:
• Consolidate debug context registration by removing duplicate entries in suites that don’t strictly need it.
• For example, if you only require detailed responses during checkout flows, keep the debug context in paying_for_order.yml (and/or checkout.yml) and remove it from the cart suites.

src/Sylius/Behat/Resources/config/suites/api/product/managing_product_association_types.yml (1)

25-25: Right call for association types as well

The debug context will help pinpoint failing API responses in association-type scenarios. No conflicts with existing contexts.

If DebugContext prints errors on every non-success response, consider adding a toggle (env var or Behat parameter) to mute output for scenarios that intentionally assert failing responses, to reduce log noise in green runs.

src/Sylius/Behat/Resources/config/suites/api/shipping/managing_shipping_methods.yml (1)

26-27: Duplicate context registration detected (setup.shipping).

The context sylius.behat.context.setup.shipping appears twice. This can instantiate the same context twice, leading to duplicated hooks (e.g., AfterStep/AfterScenario) and potentially noisy or duplicated side effects.

Apply this diff to drop the duplicate:

                 - sylius.behat.context.setup.product
-                - sylius.behat.context.setup.shipping
                 - sylius.behat.context.setup.shipping
                 - sylius.behat.context.setup.zone

If you prefer, I can scan the rest of the suite configs for similar duplicates.

src/Sylius/Behat/Resources/config/suites/api/locale/locales.yaml (1)

15-24: Noise control in CI logs.

If this suite executes many steps that intentionally probe error conditions, consider ensuring DebugContext prints only on failures or when verbose mode is enabled, to keep CI output manageable.

src/Sylius/Behat/Resources/config/suites/api/product/managing_product_variants.yml (2)

11-12: Remove duplicated transform context entry for channel

The channel transform context is listed twice. Duplicate context wiring can slow suite boot and make step resolution/order harder to reason about without functional benefits.

Apply this minimal cleanup:

                 - sylius.behat.context.transform.channel
-                - sylius.behat.context.transform.channel

---

30-31: De-duplicate setup.locale context

The locale setup context appears twice. Keep a single entry.

                 - sylius.behat.context.setup.locale
-                - sylius.behat.context.setup.locale

src/Sylius/Behat/Resources/config/suites/api/user/managing_customer_groups.yml (1)

16-19: Consider ordering: place debug context after response/save

You already did this; noting that keeping debug last among admin API contexts is a sane convention and matches other suites. If you standardize this position across all API suites, maintenance improves.

src/Sylius/Behat/Resources/config/suites/api/payment/managing_payment_methods.yaml (1)

4-39: Optional: ensure consistent debug context placement across suites

For readability and predictability, keep sylius.behat.context.api.debug immediately after sylius.behat.context.api.admin.translation (or after ...admin.save if translation is absent) in all suites.

src/Sylius/Behat/Resources/config/suites/api/promotion/managing_catalog_promotions.yml (1)

8-34: Sanity check: mixed admin and shop contexts

This suite mixes admin and shop contexts, which is fine here. Confirm the debug context’s hooks won’t produce noisy output for shop steps; if that becomes an issue, consider scoping the debug context to admin-only scenarios via tags.

src/Sylius/Behat/Context/Api/DebugErrorType.php (1)

16-20: Optional: mark as internal for test/debug scope

If this enum is intended solely for Behat diagnostics, consider marking it internal to avoid accidental usage in production code.

 namespace Sylius\Behat\Context\Api;
 
+/** @internal Diagnostic enum used by Behat debug context for error categorization. */
 enum DebugErrorType: string
 {
     case API_RESPONSE = 'API_RESPONSE';
     case EXCEPTION = 'EXCEPTION';
 }

src/Sylius/Behat/Resources/config/suites/api/homepage/viewing_products.yml (1)

19-19: Add debug context — consider placing it at the end of the contexts list.

Functional change looks fine. For consistency across suites and to hint that it’s observational-only, consider keeping debug context as the last context entry.

Apply if you prefer this ordering:

-                - sylius.behat.context.api.debug
                 - sylius.behat.context.api.shop.homepage
+                - sylius.behat.context.api.debug

src/Sylius/Behat/Resources/config/suites/api/product/viewing_product_in_admin_panel.yaml (1)

42-42: Add debug context — also align file extension convention if needed.

Change looks correct. Two small consistency points:

• Keep debug context last for readability and predictable hook expectations.
• This directory mixes .yml and .yaml. If the project has a preferred extension, consider aligning.

Proposed ordering tweak:

-                - sylius.behat.context.api.debug
                 - Sylius\Behat\Context\Api\Admin\BrowsingCatalogPromotionProductVariantsContext
+                - sylius.behat.context.api.debug

If standardizing extensions is desired:

• Rename viewing_product_in_admin_panel.yaml → viewing_product_in_admin_panel.yml and update any references (if any).

src/Sylius/Behat/Resources/config/suites/api/cart/shopping_cart.yml (1)

30-30: Add debug context — sanity-check noise in high-traffic suites.

Cart flows generate many API calls; printing errors is great, but ensure duplicates are cleared after printing to avoid repeated output across steps. If DebugContext does not call ResponseChecker::cleanErrors() after emitting, consider doing so.

Optionally keep debug context last:

-                - sylius.behat.context.api.debug
                 - sylius.behat.context.api.shop.cart
                 - sylius.behat.context.api.shop.registration
+                - sylius.behat.context.api.debug

src/Sylius/Behat/Resources/config/suites/api/account/email_verification.yml (1)

19-23: Check noise for expected 4xx flows

Email verification scenarios often expect 4xx responses (invalid/missing token). If DebugContext prints every >=400, this may add noise on passing scenarios.

• Ensure DebugContext only outputs on failed steps/scenarios, or filters out “expected” errors for steps asserting specific 4xx statuses.
• If needed, I can propose a small guard in DebugContext to check step result status before printing.

src/Sylius/Behat/Resources/config/suites/api/channel/managing_channels.yml (1)

29-35: Nit: keep the debug context at the start of API admin contexts for consistency

Purely organizational: placing the debug context immediately before the first api.admin.* context helps keep suites uniform.

Apply this reorder:

                 - sylius.behat.context.api.admin.managing_channels
                 - sylius.behat.context.api.admin.response
                 - sylius.behat.context.api.admin.save
-                - sylius.behat.context.api.debug
+                - sylius.behat.context.api.debug
                 - Sylius\Behat\Context\Api\Admin\ManagingChannelPriceHistoryConfigContext
                 - Sylius\Behat\Context\Api\Admin\ManagingChannelsBillingDataContext

Or, alternatively, move it just above the first api.admin.* line:

                 - sylius.behat.context.setup.zone

+                - sylius.behat.context.api.debug
                 - sylius.behat.context.api.admin.managing_channels
                 - sylius.behat.context.api.admin.response
                 - sylius.behat.context.api.admin.save

src/Sylius/Behat/Resources/config/suites/api/order/modifying_placed_order_address.yaml (1)

37-42: Nit: standardize placement of the debug context among admin API contexts

For readability across suites, consider placing the debug context consistently just before the first api.admin.* entry.

Reorder like so:

                 - sylius.behat.context.api.admin.managing_orders
                 - sylius.behat.context.api.admin.managing_placed_order_addresses
                 - sylius.behat.context.api.admin.response
                 - sylius.behat.context.api.admin.save
-                - sylius.behat.context.api.debug
+                - sylius.behat.context.api.debug

Or move it above the admin block:

                 - sylius.behat.context.setup.taxonomy

+                - sylius.behat.context.api.debug
                 - sylius.behat.context.api.admin.managing_orders
                 - sylius.behat.context.api.admin.managing_placed_order_addresses
                 - sylius.behat.context.api.admin.response
                 - sylius.behat.context.api.admin.save

src/Sylius/Behat/Resources/config/suites/api/promotion/managing_promotion_coupons.yml (1)

32-32: Optional: standardize context ordering for readability

Across suites, consider placing sylius.behat.context.api.debug near other diagnostic contexts (often right after sylius.behat.context.api.admin.response) to keep debugging-related contexts grouped. No functional change—purely for consistency and discoverability.

                 - sylius.behat.context.api.admin.managing_promotion_coupons
-                - sylius.behat.context.api.admin.response
-                - sylius.behat.context.api.admin.save
-                - sylius.behat.context.api.debug
+                - sylius.behat.context.api.admin.response
+                - sylius.behat.context.api.debug
+                - sylius.behat.context.api.admin.save

src/Sylius/Behat/Resources/config/suites/api/product/viewing_price_history_after_catalog_promotions.yml (1)

25-25: Minor consistency suggestion: position debug context near response context

If this suite ever adds sylius.behat.context.api.admin.response, consider grouping the debug context immediately after it for uniformity with other suites.

src/Sylius/Behat/Resources/config/suites/api/order/managing_orders.yml (1)

54-56: Add debug context: placement looks correct; trim trailing spaces on email context

• Good call placing sylius.behat.context.api.debug right after the admin managing orders context and before the email context.
• Line 56 has trailing spaces after sylius.behat.context.api.email. Trim to avoid YAML linters or future diffs churn.

Apply this diff:

-                - sylius.behat.context.api.email                
+                - sylius.behat.context.api.email

src/Sylius/Behat/Resources/config/suites/api/order/order_history.yaml (1)

34-34: OK, but consider normalizing file extensions to .yml for consistency

Change is correct. For repo-wide consistency (most files in this tree use .yml), consider renaming this file to .yml. This avoids minor tooling surprises and keeps conventions uniform.

You can do:

git mv src/Sylius/Behat/Resources/config/suites/api/order/order_history.yaml \
       src/Sylius/Behat/Resources/config/suites/api/order/order_history.yml

src/Sylius/Behat/Resources/config/suites/api/promotion/removing_catalog_promotions.yml (1)

29-29: LGTM: debug context added between admin and shop contexts

Solid placement. Small nit: standardize placement across suites (e.g., always just before the first sylius.behat.context.api.* context, or always at the end of the contexts block) to ease scanning and future maintenance.

src/Sylius/Behat/Resources/config/suites/api/taxation/applying_taxes.yml (1)

40-40: Optional: standardize placement of the debug context

To keep suites consistent and to avoid any hook interleaving surprises, consider appending the debug context at the end of the contexts list in all suites.

src/Sylius/Behat/Resources/config/suites/api/promotion/applying_promotion_coupon.yml (1)

35-35: Optional: control verbosity via env/config if CI logs become noisy

If the debug output is always-on, large feature runs might get verbose. Consider an env flag (e.g., BEHAT_DEBUG_API_ERRORS) checked in DebugContext to toggle printing while keeping error collection active.

If you want, I can sketch how to inject a boolean parameter into DebugContext via services XML and toggle printing based on an env var.

src/Sylius/Behat/Resources/config/suites/api/shipping/applying_shipping_method_rules.yml (1)

36-36: Minor consistency nit: keep debug context grouped or last across all suites

For easier maintenance and predictable hook execution, consider keeping the debug context consistently last in the list across all suites.

src/Sylius/Behat/Resources/config/suites/api/promotion/managing_promotions.yml (1)

41-41: Optional ordering consistency

If DebugContext relies on AfterStep/AfterScenario hooks, consider moving it to the end of the context list to standardize execution sequence across suites.

src/Sylius/Behat/Resources/config/suites/api/payment/managing_payments.yml (1)

28-28: Good addition; placement within admin API contexts is consistent

Sits with the other admin API contexts; should integrate cleanly with existing hooks.

Consider standardizing the position of the debug context across admin suites (e.g., always just before the first api.* context) for easier scanning in reviews.

src/Sylius/Behat/Resources/config/suites/api/promotion/applying_promotion_rules.yml (1)

40-40: LGTM — debug context added before api.shop contexts

This aligns with other promotion-related suites and should provide useful per-step diagnostics.

If other promotion suites place the debug context immediately before the api.* contexts, mirror that here for uniformity across promotion configs.

src/Sylius/Behat/Resources/config/suites/api/checkout/checkout.yml (1)

57-57: LGTM — debug context for checkout suite

Placed just after CatalogPromotionContext and before api.* contexts; matches the broader convention in this PR.

While unrelated to this change, noticed duplicated context entries earlier (Lines 42–43: sylius.behat.context.setup.geographical appears twice). Consider removing the duplicate to keep the suite concise.

src/Sylius/Behat/Client/ApiPlatformClient.php (2)

356-359: Use expressive helpers for 4xx/5xx detection and simplify condition

isSuccessful() check is redundant when you already guard on >= 400. Prefer the dedicated helpers for clarity.

Apply:

-        if (!$response->isSuccessful() && $response->getStatusCode() >= 400) {
-            $this->responseChecker->appendError($response);
-        }
+        if ($response->isClientError() || $response->isServerError()) {
+            $this->responseChecker->appendError($response);
+        }

---

336-364: Optional: capture thrown exceptions as debug entries

If the BrowserKit client throws (transport/runtime) before a Response exists, these errors won’t be recorded. Since DebugErrorType includes EXCEPTION, consider wrapping the request dispatch in try/catch and delegating an “exception” record to the checker (or a dedicated collector). This would give parity with API response logging.

Example sketch (requires a new method on the checker or a separate DebugErrorCollector):

try {
    $this->client->request(
        $request->method(),
        $request->url(),
        $request->parameters(),
        $request->files(),
        $request->headers(),
        $request->content(),
    );
} catch (\Throwable $e) {
    // e.g. $this->responseChecker->appendException($request, $e);
    throw $e;
}

If you’d like, I can prepare a minimal change set (plus tests) to add this capability.

src/Sylius/Behat/Resources/config/services/api.xml (1)

32-32: Prefer aliasing the interface to the implementation (Symfony convention).

Defining the service with the interface id works, but using a concrete service id for the implementation and aliasing the interface improves clarity and tooling support.

Apply:

-        <service id="Sylius\Behat\Client\ResponseCheckerInterface" class="Sylius\Behat\Client\ResponseChecker"/>
+        <service id="Sylius\Behat\Client\ResponseChecker" class="Sylius\Behat\Client\ResponseChecker">
+            <!-- Optional: auto-reset between Symfony kernel resets -->
+            <!-- <tag name="kernel.reset" method="reset"/> -->
+        </service>
+        <service id="Sylius\Behat\Client\ResponseCheckerInterface" alias="Sylius\Behat\Client\ResponseChecker"/>

If you decide to enable kernel resets later, uncomment the tag and add a simple reset() method to the class (see comment on ResponseChecker.php).

src/Sylius/Behat/Client/ResponseChecker.php (1)

305-321: Add a reset hook to avoid any cross-scenario leakage (optional).

The service is stateful by design and relies on DebugContext to clear errors after each step. As a safety net (e.g., on abrupt failures), consider adding a reset() method and tagging the service with kernel.reset so the container clears state on kernel resets.

Apply in this class:

     public function getDebugErrors(): array
     {
         return $this->errors;
     }
+
+    /**
+     * Optional: allows Symfony's "kernel.reset" to clear service state.
+     * Tag the service with <tag name="kernel.reset" method="reset"/> to activate.
+     */
+    public function reset(): void
+    {
+        $this->cleanErrors();
+    }

And (if you choose to adopt it) add the XML tag as shown in the api.xml comment. I can wire this across the PR if you want.

src/Sylius/Behat/Context/Api/DebugContext.php (1)

49-66: Harden JSON formatting and consider a scenario-level reset.

• Guard against json_encode returning false and preg_replace returning null.
• Optional: clear stacks at scenario start to avoid any leftovers if previous cleanup was skipped.

     /** @AfterScenario */
     public function afterScenario(): void
     {
         if (!empty($this->errorStack)) {
             $output = new ConsoleOutput();
             $styleKey = new OutputFormatterStyle('cyan');
             $styleValue = new OutputFormatterStyle('green');
             $output->getFormatter()->setStyle('key', $styleKey);
             $output->getFormatter()->setStyle('value', $styleValue);
 
-            $json = json_encode($this->errorStack, \JSON_PRETTY_PRINT);
-
-            $formattedJson = preg_replace('/"([^"]+)":/', '<key>"$1"</key>:', $json);
-            $formattedJson = preg_replace('/: "([^"]+)"/', ': <value>"$1"</value>', $formattedJson);
-
-            $output->writeln($formattedJson);
+            $json = json_encode($this->errorStack, \JSON_PRETTY_PRINT | \JSON_UNESCAPED_SLASHES | \JSON_UNESCAPED_UNICODE);
+            if ($json === false) {
+                $output->writeln('<error>Failed to encode API debug errors</error>');
+                return;
+            }
+
+            $formattedJson = preg_replace('/"([^"]+)":/', '<key>"$1"</key>:', $json) ?? $json;
+            $formattedJson = preg_replace('/: "([^"]+)"/', ': <value>"$1"</value>', $formattedJson) ?? $formattedJson;
+
+            $output->writeln($formattedJson);
         }
     }
+
+    /** @BeforeScenario */
+    public function beforeScenario(): void
+    {
+        // Defensive cleanup in case a previous scenario aborted mid-step
+        $this->errorStack = [];
+        $this->responseChecker->cleanErrors();
+    }

If you’d like, I can also switch the pretty-printing to VarDumper for richer CLI output.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

src/Sylius/Behat/Resources/config/suites/api/user/managing_administrators.yml (1)

22-23: LGTM — enabling the debug context for this suite is appropriate.

Placement after API response/save contexts makes sense; the context only uses hooks and has no step definitions, so ordering is safe.

src/Sylius/Behat/Resources/config/suites/api/admin/locale.yaml (1)

23-24: LGTM — consistent addition of the debug context.

No ordering conflicts with existing transform/setup contexts.

src/Sylius/Behat/Resources/config/suites/api/addressing/managing_countries.yaml (1)

23-24: LGTM — debug context added.

Consistent with other suites. No functional concerns.

src/Sylius/Behat/Resources/config/suites/api/promotion/applying_catalog_promotions.yml (1)

32-33: LGTM — debug context placement makes sense.

Positioned after admin save; hooks-only context so ordering is flexible.

src/Sylius/Behat/Resources/config/suites/api/account/login.yaml (2)

21-21: Add debug context — looks good.

Registering sylius.behat.context.api.debug in this suite is consistent with the PR’s goal and won’t affect step resolution.

---

21-21: DebugContext Hook and State Reset Verified – No Changes Required

I’ve confirmed that:

• The DebugContext::afterStep() method is annotated with @AfterStep and, since the debug context is registered last in common.xml, it will run after other contexts at the default priority.
• Within that hook, any collected errors are output before calling $this->responseChecker->cleanErrors(), ensuring the checker’s state is reset at the end of each step.
• Although ResponseChecker is a shared service, its per-step cleanup guarantees no stale errors persist between steps.

No further changes are needed here.

src/Sylius/Behat/Resources/config/suites/api/addressing/managing_zones.yml (1)

24-24: Add debug context — looks good.

The placement alongside admin API contexts is sensible.

src/Sylius/Behat/Resources/config/suites/api/product/managing_product_options.yml (1)

27-27: Add debug context — looks good.

Matches the pattern used in other API suites.

src/Sylius/Behat/Resources/config/suites/api/taxon/managing_taxons.yml (1)

28-28: Add debug context — looks good.

No conflicts with existing admin contexts.

src/Sylius/Behat/Resources/config/suites/api/account/customer.yml (1)

37-37: Add debug context — looks good.

Helpful in customer flows with multiple chained API calls.

src/Sylius/Behat/Resources/config/suites/api/shipping/managing_shipping_categories.yml (1)

20-20: Debug context presence confirmed

• Verified that sylius.behat.context.api.debug appears exactly once at line 20 in src/Sylius/Behat/Resources/config/suites/api/shipping/managing_shipping_categories.yml.

No further action required—changes are aligned with other admin API suites.

src/Sylius/Behat/Resources/config/suites/api/shipping/managing_shipping_methods.yml (2)

35-35: Add debug context for API error surfacing — looks good.

Including sylius.behat.context.api.debug here will help correlate failing API responses with their originating steps.

---

31-36: Hook execution order — confirm DebugContext priorities.

If DebugContext relies on running last to print/flush collected errors, ensure its hook priority is lower (runs later) than other AfterStep/AfterScenario hooks in this suite. Config order isn’t guaranteed to control hook order; Behat priorities do.

src/Sylius/Behat/Resources/config/suites/api/product/managing_product_attributes.yml (2)

24-24: Debug context inclusion acknowledged.

Good addition; it should improve failure diagnostics for product attribute API steps.

---

20-25: Consistency check across product-related suites.

For consistent diagnostics, ensure all product-oriented API suites (options, association types, taxons, etc.) also include the debug context in this PR or a follow-up, to avoid uneven visibility of API errors.

src/Sylius/Behat/Resources/config/suites/api/account/customer_registration.yml (2)

22-22: Adding debug context to customer registration — approved.

This should help when registration flows return non-2xx responses (validation, uniqueness, etc.).

---

22-25: Verify hook priority vs. email context.

If email assertions/cleanups have AfterStep/AfterScenario hooks, confirm DebugContext’s priority ensures errors are printed after those hooks have had a chance to act, or that order doesn’t matter for your printing logic.

src/Sylius/Behat/Resources/config/suites/api/locale/locales.yaml (1)

19-19: Locales suite gains debug context — approved.

Placement among shop contexts is fine; it should capture non-success locale/cart/channel endpoints used in these scenarios.

src/Sylius/Behat/Resources/config/suites/api/locale/managing_locales.yaml (2)

20-20: Managing locales now debuggable — good change.

This will surface API validation/permission errors next to the failing step for admin locale management.

---

19-21: Service wiring sanity check.

Please confirm sylius.behat.context.api.debug is registered in services/contexts/api/common.xml for the 2.1 target and that ApiPlatformClient is injecting ResponseCheckerInterface in this branch, otherwise the debug context may have nothing to print.

src/Sylius/Behat/Resources/config/suites/api/product/managing_product_variants.yml (1)

46-46: Add debug context — LGTM

The placement right after admin translation keeps the admin API contexts grouped and should allow the debug hooks to observe responses from prior steps.

src/Sylius/Behat/Resources/config/suites/api/taxation/managing_tax_categories.yml (2)

19-19: Add debug context — LGTM

Placed after admin save/response which is consistent with other suites and should ensure response collection is available for the following steps.

---

4-24: Service wiring verification successful

All checks confirm that the Behat API debugging context and related interfaces are correctly wired:

• The sylius.behat.context.api.debug service is defined in src/Sylius/Behat/Resources/config/services/contexts/api/common.xml and injects the ResponseCheckerInterface as expected.
• The ResponseCheckerInterface declares both cleanErrors(): void and getDebugErrors(): array methods in ResponseCheckerInterface.php.
• The ApiPlatformClient constructor (in ApiPlatformClient.php) receives a ResponseCheckerInterface instance via a readonly property, ensuring the updated interface is used.

No further changes are required.

src/Sylius/Behat/Resources/config/suites/api/user/managing_customer_groups.yml (1)

19-19: Add debug context — LGTM

Keeping admin managing/response/save contexts and appending the debug context is safe and preserves existing step definitions while enabling error printing.

src/Sylius/Behat/Resources/config/suites/api/payment/managing_payment_methods.yaml (1)

34-34: Add debug context — LGTM

Inserted after admin translation; consistent with other suites and should capture non-2xx responses during steps.

src/Sylius/Behat/Resources/config/suites/api/promotion/managing_catalog_promotions.yml (1)

31-31: Add debug context — LGTM

Placed before shop contexts so it participates in hooks for admin-side steps and still remains available for later steps if needed.

src/Sylius/Behat/Resources/config/suites/api/user/managing_users.yml (2)

21-21: Enable API debug context — good addition

Adding sylius.behat.context.api.debug should help surface API failures tied to steps without affecting existing steps.

---

20-22: Contexts are not redundant – no changes needed

Each of the contexts loaded in managing_users.yml (lines 20–22) has a distinct responsibility and should all remain:

• sylius.behat.context.api.admin.response provides step definitions for asserting API response success or handling violations via the shared ResponseContext.
• sylius.behat.context.api.debug captures and pretty-prints debug errors after each scenario, without affecting response assertions.
• sylius.behat.context.api.shop.login implements the customer login flow, which is separate from admin login and required by the suite’s scenarios.

Removing any of these would break existing step definitions or disable the debug output; there’s no overlap in functionality.

Likely an incorrect or invalid review comment.

src/Sylius/Behat/Resources/config/suites/api/product/viewing_products.yml (1)

36-36: LGTM: Debug context added to product viewing suite

Good, consistent with other API suites; should improve failure diagnosability without affecting step definitions.

src/Sylius/Behat/Context/Api/DebugErrorType.php (1)

16-20: LGTM: Minimal, clear string-backed enum

Enum cases are explicit and future-proof. Works well for structured reporting and serialization.

src/Sylius/Behat/Resources/config/suites/api/currency/currencies.yml (1)

18-18: LGTM: Debug context introduced to currencies suite

Consistent adoption; no config pitfalls spotted.

src/Sylius/Behat/Resources/config/suites/api/account/address_book.yml (1)

36-36: LGTM: Debug context added to address book suite

Alignment with the broader test suites; should aid triage of API-related failures.

src/Sylius/Behat/Resources/config/suites/api/channel/channels.yml (1)

15-15: Debug context wiring verified—nothing critical outstanding

• The sylius.behat.context.api.debug service is declared exactly once in src/Sylius/Behat/Resources/config/services/contexts/api/common.xml.
• The DebugContext class implements both @AfterStep and @AfterScenario hooks (default priority). If you need deterministic “last-run” behavior, you can add explicit negative priorities (e.g. @AfterStep(priority=-10), @AfterScenario(priority=-10)) or simply move this context entry to the end of your suite.
• The ResponseCheckerInterface exposes cleanErrors() and getDebugErrors() methods.
• The ApiPlatformClient appends non-success HTTP responses via $this->responseChecker->appendError().

Optional readability tweak—place debug context last in your suite:

-                - sylius.behat.context.api.debug
                 - sylius.behat.context.api.shop.channel
                 - sylius.behat.context.api.shop.homepage
+                - sylius.behat.context.api.debug

src/Sylius/Behat/Resources/config/suites/api/product/viewing_price_history.yml (1)

25-25: Confirm admin API contexts for viewing price history
The sylius.behat.context.api.debug entry is present and already last in the contexts: list of
src/Sylius/Behat/Resources/config/suites/api/product/viewing_price_history.yml.
Please double-check that all required admin API contexts (e.g., channel_pricing_log_entry, managing_product_variants, save) remain in the PR, as scenarios tagged @viewing_price_history && @api depend on them.

src/Sylius/Behat/Resources/config/suites/api/shipping/viewing_shipping_methods.yml (1)

35-39: Debug context present in all API suites

• Verified that every file in src/Sylius/Behat/Resources/config/suites/api/ contains exactly one occurrence of sylius.behat.context.api.debug.
• No suites are missing the debug context, and there are no duplicate entries.

src/Sylius/Behat/Resources/config/suites/api/product/viewing_product_reviews.yml (1)

21-24: LGTM; consider ensuring the debug hook runs last

If DebugContext uses AfterStep/AfterScenario hooks, make sure its hook priority ensures it runs after other API contexts manipulating responses. YAML order isn’t a reliable execution guarantee in Behat.

Please confirm DebugContext’s hook annotations explicitly set priority (e.g., a higher magnitude to run deterministically last among AfterStep hooks).

src/Sylius/Behat/Resources/config/suites/api/product/viewing_product_variants.yml (2)

21-21: LGTM: Debug context added to API suite

Adding sylius.behat.context.api.debug here aligns with the PR goal and should improve post-step diagnostics for API failures in this suite. Placement before the api.shop.* contexts is fine.

---

21-21: Debug context service verified – no duplicates detected

• The sylius.behat.context.api.debug service is defined in src/Sylius/Behat/Resources/config/services/contexts/api/common.xml (line 36).
• The DebugContext class exists at src/Sylius/Behat/Context/Api/DebugContext.php (namespace Sylius\Behat\Context\Api, class declared on line 22).
• No suite YAML file includes the sylius.behat.context.api.debug entry more than once.

All checks pass.

src/Sylius/Behat/Resources/config/suites/api/promotion/managing_promotion_coupons.yml (1)

32-32: LGTM: Debug context enabled for promotion coupons management

Good addition; this will surface failing API responses alongside the step.

src/Sylius/Behat/Resources/config/suites/api/taxation/managing_tax_rates.yml (2)

23-23: LGTM: Debug context included for tax rates management

Looks correct and consistent with the broader PR pattern.

---

23-23: DebugContext hook compatibility confirmed: ordering is safe
The DebugContext only defines @AfterStep and @AfterScenario hooks—no before hooks are present—so its position in the suite’s context list does not affect initialization.

• If any @BeforeStep or @BeforeScenario logic is ever added to DebugContext, ensure this context is listed before other API contexts to initialize early.

src/Sylius/Behat/Resources/config/suites/api/user/managing_customers.yml (1)

33-33: LGTM: Debug context added to customers management suite

This should help correlate failing API calls with the exact Behat step during customer management scenarios. Placement between admin save and shop login contexts is acceptable.

src/Sylius/Behat/Resources/config/suites/api/product/viewing_price_history_after_catalog_promotions.yml (1)

25-25: LGTM: Debug context appended to price history after catalog promotions

Good call—errors during catalog promotion operations can be opaque; this will improve troubleshooting.

src/Sylius/Behat/Resources/config/suites/api/order/managing_orders.yml (1)

55-55: Confirm debug context service registration and usage

• The service sylius.behat.context.api.debug is declared in
  src/Sylius/Behat/Resources/config/services/contexts/api/common.xml (line 36).
• It is referenced exactly once in each API suite (including managing_orders.yml at line 55).
• No suite file includes this context multiple times.

No changes required.

src/Sylius/Behat/Resources/config/suites/api/shipping/managing_shipments.yml (1)

34-36: Add debug context: ordering matches the intended pattern

Placed right after sylius.behat.context.api.admin.managing_shipments and before sylius.behat.context.api.email, which is consistent with other suites.

If not already done, please run the verification script from my other comment to ensure there are no duplicate inclusions across suites.

src/Sylius/Behat/Resources/config/suites/api/contact/requesting_contact.yml (1)

16-19: Add debug context: fits correctly before API email context

Ordering looks good: after setup contexts and before sylius.behat.context.api.email. This should allow the debug hook to capture API errors tied to steps without affecting step resolution.

Use the shared verification script to confirm single inclusion and proper service registration.

src/Sylius/Behat/Resources/config/suites/api/admin/login.yml (1)

19-22: Add debug context: consistent placement in admin suite

Inserted after admin API contexts and before email; consistent with the pattern used elsewhere. No issues spotted.

Leverage the shared verification script to ensure consistency across all admin-related suites.

src/Sylius/Behat/Resources/config/suites/api/product/adding_product_review.yml (1)

21-25: Add debug context: sensible positioning with shop API contexts

Positioned immediately before shop API contexts and after security setup; this should work well with AfterStep/AfterScenario hooks in the debug context.

Run the shared verification script to validate presence and uniqueness across product-related suites as well.

src/Sylius/Behat/Resources/config/suites/api/shipping/applying_shipping_fee.yml (1)

43-43: LGTM: consistent placement among shop API contexts

The debug context is added right before the shop API contexts, consistent with other suites in this PR. This should reliably print API errors tied to the failing step without interfering with step matching.

src/Sylius/Behat/Resources/config/suites/api/cart/accessing_cart.yml (1)

32-32: LGTM: enables per-step API error visibility for cart scenarios

The addition is correct and positioned analogously to other API shop suites. No ordering concerns since the context only contributes hooks.

src/Sylius/Behat/Resources/config/suites/api/inventory/managing_inventory.yaml (2)

33-33: Adding sylius.behat.context.api.debug here looks good

The context is correctly added to the api_managing_inventory suite and placed near admin API response/save contexts, which makes sense for debugging API-related steps.

---

33-33: DebugContext ordering is already correct

• Verified that DebugContext in src/Sylius/Behat/Context/Api/DebugContext.php declares both @AfterStep and @AfterScenario hooks, confirming its role in gathering post-step and post-scenario debug output.
• In src/Sylius/Behat/Resources/config/suites/api/inventory/managing_inventory.yaml, the entry

  - sylius.behat.context.api.debug

  is already the last context listed (immediately before the filters: section), ensuring that debug hooks run after all other contexts in this suite.
• No adjustments needed for hook ordering in this file.

src/Sylius/Behat/Resources/config/suites/api/taxation/applying_taxes.yml (1)

40-40: Good addition of sylius.behat.context.api.debug to the taxation suite

Enables unified API error visibility during tax application scenarios without altering suite tags/JS settings.

src/Sylius/Behat/Resources/config/suites/api/promotion/applying_promotion_coupon.yml (1)

35-35: LGTM: debug context added to promotion coupon suite

This aligns the suite with the broader debugging capability introduced in the PR.

src/Sylius/Behat/Resources/config/suites/api/shipping/applying_shipping_method_rules.yml (1)

36-36: Debug context correctly enabled for shipping method rules suite

No conflicts with existing contexts; consistent with other API suites in this PR.

src/Sylius/Behat/Resources/config/suites/api/promotion/managing_promotions.yml (1)

41-41: Nice: debug context added without removing existing admin translation context

Both translation and debug contexts being present should preserve existing steps while adding error debugging. Good balance between functionality and safety.

src/Sylius/Behat/Resources/config/suites/api/admin/security.yml (1)

21-21: LGTM — debug context enabled for admin security suite

No ordering concerns; DebugContext should not interfere with step definitions.

src/Sylius/Behat/Resources/config/suites/api/currency/managing_currencies.yml (1)

19-19: Added API debug context to the suite — looks good

This enables per-step API error surfacing for the currency suite. No ordering conflicts detected with existing transform/setup contexts.

src/Sylius/Behat/Resources/config/services/contexts/api/common.xml (1)

36-38: DI registration of DebugContext is correct

• Public service fits Behat’s context discovery via service IDs.
• Injecting the ResponseCheckerInterface keeps the context decoupled from the client.

No issues from a wiring perspective given other contexts already reference the same interface service.

src/Sylius/Behat/Resources/config/suites/api/product/managing_product_reviews.yml (1)

25-25: Added API debug context to product reviews — OK

Consistent with other API suites and placed after response/save contexts. Good for consolidated debugging output.

src/Sylius/Behat/Resources/config/suites/api/admin/dashboard.yaml (1)

36-36: Admin dashboard suite now includes API debug context — OK

This should help pinpoint failing steps on dashboard-related API interactions.

src/Sylius/Behat/Resources/config/services/api.xml (1)

16-22: ApiPlatformClient wiring: constructor arg order looks correct.

The injected ResponseCheckerInterface is placed after RequestFactory and before the authorization header, matching ApiPlatformClient’s constructor. Child services supply the "section" argument, so the inheritance chain remains valid.

src/Sylius/Behat/Client/ResponseChecker.php (1)

23-29: State initialization for error buffer is fine.

Private typed array + explicit constructor initialization is clear and safe.