Implementation of ExactMatch (and Substring) is broken

Inizia da datadog_sync/utils/filter.py intorno alla riga 150 e leggi la sezione del README relativa alla deprecazione di substring e ExactMatch. Determina se la risoluzione prevista consiste nel correggere gli operatori deprecati o nel chiarire nella documentazione l’escaping richiesto; il lavoro è completo quando il comportamento scelto è coperto dai controlli esistenti del progetto e corrisponde alle indicazioni documentate.

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?