You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Extension example catches its own assertions and cannot detect failed deletion #180
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()
raiseAssertionError("Expected to fail when retrieving deleted extension")
exceptExceptionasexc:
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.
Activity