Extension example catches its own assertions and cannot detect failed deletion
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 84/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Tranquilo
- Stack tecnológico
- python
- Área
- testing-qa
Línea de trabajo
Comienza con los dos bloques de verificación de eliminación en examples/playwright_extensions.py:127-132 y 134-143; después, inspecciona cómo examples/e2e/test_playwright.py ejecuta el ejemplo. Asegúrate de que un éxito inesperado no se trate como un fallo esperado y ejecuta la prueba E2E correspondiente para verificar que se detectan las regresiones de eliminación.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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-132examples/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.
- Lenguaje dominante
- Python
- Estrellas
- 93
- Forks
- 16
- Merge medio
- 11 min
- PR fusionados (30 d)
- 3
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de browserbase/sdk-python
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
browserbase/sdk-python#182 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
browserbase/sdk-python#179 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
browserbase/sdk-python#178 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
browserbase/sdk-python#176 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
browserbase/sdk-python#175 ·
Todos los issues de browserbase/sdk-python
Issues similares
-
essnmx good first issue
Dificultad 1/5 Menos de una hora Aptitud para principiantes 95/100
-
[Feature] 奇物选择添加优先级 Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
syfoud/Simulated_Scepter#174 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Giskard-AI/giskard-oss#2840 · 1 comentario ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Abiertoarea: repo bug perceived difficulty: 2
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
yeti-platform/yeti#1380 ·