[Bug] `on_refresh_success` is not called after the last matching feature flag is deleted
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 52/100
Línea de trabajo
Start with the AzureAppConfigurationProvider.refresh() flow and the load() configuration shown in the report, then review related issue #49108 first. Reproduce the two-deletion sequence with feature_flag_refresh_enabled and on_refresh_success enabled. Done means the callback is invoked after the final matching feature flag is deleted without leaving stale provider state.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
- Package Name: azure-appconfiguration-provider
- Package Version: 2.5.0, 2.5.1
- Operating System: macOS
- Python Version: 3.14
Describe the bug
When feature flag refresh is enabled, AzureAppConfigurationProvider.refresh() does not invoke on_refresh_success after the last feature flag matching the configured selector is deleted from Azure.
To Reproduce
Steps to reproduce the behavior:
- Create two feature flags:
test_1andtest_2. - Load configuration with
feature_flag_enabled=True,feature_flag_refresh_enabled=Trueandon_refresh_success=callbackset. - Delete
test_1. - Wait for the refresh interval and call
refresh(). - Verify the callback is invoked.
- Delete the remaining
test_2. - Wait again and call
refresh(). - Observe that the callback is not invoked.
Actual behavior
- Deleting
test_1: refresh detects the change and calls the callback. - Deleting the last flag
test_2: refresh does not call the callback.
Expected behavior
refresh() should invoke on_refresh_success after the last matching feature flag is deleted.
Screenshots
Additional context
from azure.appconfiguration.provider import load
from azure.appconfiguration.provider._models import SettingSelector
CONNECTION_STRING = "..."
REFRESH_INTERVAL = 5
def callback():
print("callback called")
config = load(
connection_string=CONNECTION_STRING,
feature_flag_enabled=True,
feature_flag_refresh_enabled=True,
feature_flag_selectors=[SettingSelector(key_filter="*", label_filter="my_custom_label")],
on_refresh_success=callback,
refresh_interval=REFRESH_INTERVAL,
)
print(config["feature_management"]["feature_flags"])
# [
# {'conditions': {'client_filters': []},
# 'description': None,
# 'display_name': None,
# 'enabled': False,
# 'id': 'test_1',
# 'telemetry': {'metadata': {'ETag': 'hgRX_0yhNXOSl1vtyakBlTrNeEmL2GIBoxnnsw5gsmA'}}},
# {'conditions': {'client_filters': []},
# 'description': None,
# 'display_name': None,
# 'enabled': False,
# 'id': 'test_2',
# 'telemetry': {'metadata': {'ETag': 'uIOfSyJmWUw2XL5_AQf9eX0RS-MILlR6Xev59r_fdao'}}}
# ]
# Delete the "test_1" feature flag from Azure. After REFRESH_INTERVAL has elapsed, call refresh().
config.refresh()
# Expected and actual:
# The callback is called and "callback called" is printed.
# Delete the last remaining feature flag, "test_2", from Azure. After REFRESH_INTERVAL has elapsed, call refresh().
config.refresh()
# Expected:
# The callback is called and "callback called" is printed.
# Actual:
# The callback is not called and "callback called" is not printed.
This issue is related to #49108 .
I think #49108 should be fixed first. Calling the refresh callback after the last feature flag is deleted is not very useful while the provider itself still keeps the stale feature flag in its state.
- Lenguaje dominante
- Python
- Estrellas
- 5.6k
- Forks
- 3.4k
- Merge medio
- 2 d 1 min
- PR fusionados (30 d)
- 218
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la 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 Azure/azure-sdk-for-python
-
Evaluation Service Attention
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Azure/azure-sdk-for-python#49190 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Update CODEOWNERSAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
Azure/azure-sdk-for-python#49183 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Evaluation Service Attention
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Azure/azure-sdk-for-python#49153 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Search Service Attention
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Azure/azure-sdk-for-python#48555 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Azure.Core customer-reported feature-request needs-team-attention
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Azure/azure-sdk-for-python#47186 ·
Los mantenedores suelen responder en 1 día
Todos los issues de Azure/azure-sdk-for-python
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
kornia/kornia#5263 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Metadata correction for W16-5400Abiertoapproved correction metadata
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
acl-org/acl-anthology#10133 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
BasedHardware/omi#20084 ·
Los mantenedores suelen responder en 1 día
-
bug needs-acceptance wg/evaluation-quality
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
vllm-project/semantic-router#4424 ·
Los mantenedores suelen responder en 1 día