Extension example catches its own assertions and cannot detect failed deletion

まず examples/playwright_extensions.py:127-132 と 134-143 にある 2 つの削除検証ブロックから始め、次に examples/e2e/test_playwright.py がその例をどのように実行しているかを確認します。予期しない成功が期待される失敗として扱われないことを確認し、削除のリグレッションが検出されることを検証するために、関連する E2E テストを実行します。

Description

The extension example's two deletion-verification blocks catch their own AssertionError. If retrieving a deleted extension or creating a session with it unexpectedly succeeds, the code raises AssertionError, immediately catches it with except Exception, and prints that failure occurred "as expected".

Code reference

• examples/playwright_extensions.py:127-132
• examples/playwright_extensions.py:134-143

Reproduction

The control-flow problem can be demonstrated without Browserbase credentials:

try:
    # Simulate get_extension() unexpectedly succeeding.
    object()
    raise AssertionError("Expected to fail when retrieving deleted extension")
except Exception as exc:
    print(f"Failed as expected: {exc}")

The output claims an expected failure even though the operation succeeded and only the example's own assertion failed.

Expected behavior

Only the API operation should be inside the try, with the success assertion in else, or the code should catch the specific expected Browserbase exception. Unexpected success must fail the example/E2E test.

Actual behavior

Both negative checks are guaranteed to print an expected-failure message for either outcome, so regressions in extension deletion can pass silently.

Why it matters

examples/e2e/test_playwright.py exercises this example. False-positive cleanup checks weaken E2E coverage for deletion semantics and can mask a server or SDK regression.