Implementation of ExactMatch (and Substring) is broken
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
- 38/100
Línea de trabajo
Empieza por datadog_sync/utils/filter.py alrededor de la línea 150 y lee la sección del README sobre la obsolescencia de substring y ExactMatch. Determina si la resolución prevista es corregir los operadores obsoletos o aclarar en la documentación el escape requerido; se considera terminado cuando el comportamiento elegido está cubierto por las comprobaciones existentes del proyecto y coincide con las indicaciones documentadas.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Hello,
I was experimenting with datadog-sync and the filter option.
I wanted to exactly match a single Synthetics Test with name [Synthetics][Multilocator] Browser test to test multilocator in org 2 for Conductor gates.
I took the recommended approach and wrote a Regular expression, wrapping the name with ^ and $.
--filter "Type=synthetics_tests;Name=name;Value=^[Synthetics][Multilocator] Browser test to test multilocator in org 2 for Conductor gates$"
It didn't work.
I realized I had [ and ] in the name, so I escaped them.
--filter "Type=synthetics_tests;Name=name;Value=^\[Synthetics\]\[Multilocator\] Browser test to test multilocator in org 2 for Conductor gates$"
Since it's a pain and a pitfall to escape chars for a simple exact match, I gave a try at the ExactMatch Operator despite it being deprecated.
--filter "Type=synthetics_tests;Name=name;Value=[Synthetics][Multilocator] Browser test to test multilocator in org 2 for Conductor gates;Operator=ExactMatch"
It didn't work.
Because of the deprecation, I had an idea what could be the cause, and indeed, it's a bug in the code, simply wrapping the string without RegExp escaping the content:
elif operator_lower == EXACT_MATCH_OPERATOR:
reg_exp = f"^{f_dict[FILTER_VALUE_KEY]}$"
On the bug itself
I understand the rational for maintainers to try and have a single implementation and it's nice to have put a deprecation notice.
The feature is only deprecated at the moment, it believe should still work (a reasonable expectation from a user perspective), and, as a user, I would expect a fix.
However, the feature is deprecated, so depending on when it will be effectively deleted, possibly the best option is to update documentation and warn users that strings must be Regexp-escaped regardless of the operator.
WDYT?
Let me know when it's going to be deleted and I can offer to contribute the doc fix in the meantime if it helps.
On the deprecation of operators ExactMatch and Substring
I would like to challenge the deprecation of these operators.
I understand maintainers would like to simplify the code and I agree the Regexp operator covers all needs in one shot.
However, I would like to point that this choice puts an expectation, a responsibility and extra complexity on users that I don't find reasonable.
Yes, the tool is probably intended for devs, yes they can certainly figure how to escape their strings.
However, I doubt going beyond exact match or substring is so common of a use case (and it's only an opinion, happy to be proven wrong with data and numbers).
This means the escaping problem I faced will be solved numerous times at DD (wasting time and resources) while it could be solved just once with an improvement (revert?) to this tool and not using a regexp implementation (also slower) for everything.
WDYT?
- Lenguaje dominante
- Python
- Estrellas
- 81
- Forks
- 26
- Merge medio
- 10 h 34 min
- PR fusionados (30 d)
- 17
Preparar el entorno
- Incluye un Dockerfile o un 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 DataDog/datadog-sync-cli
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
DataDog/datadog-sync-cli#729 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
DataDog/datadog-sync-cli#698 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
CCM ResourcesAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
DataDog/datadog-sync-cli#697 ·
Los mantenedores suelen responder en 1 día
-
All security_monitoring_rules fail to sync: cases.condition is stripped from the create payloadAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 68/100
DataDog/datadog-sync-cli#598 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
DataDog/datadog-sync-cli#597 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
Todos los issues de DataDog/datadog-sync-cli
Issues similares
-
mermaid_extract.py silently discards single-line state-diagram notes; sequence notes are keptAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
cathrynlavery/diagram-design#441 ·
Los mantenedores suelen responder en 2 días
-
[Cleanup] Include the public header in work_split.cppPosiblemente ocupada @blozano-tt la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
tenstorrent/tt-metal#60850 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
backend::sglang bug language::python observability
Dificultad 2/5 Medio día Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
OpenShot/openshot-qt#6202 ·
Los mantenedores suelen responder en 1 día