Termos mais procurados:
tive uma ideia aqui. e se a GN mandar um request para webhookURL/txidmatch passando o txid recebido, com um timeout de uns 3 segundos, e o EC responde se a GN deve ou não aceitar o recebimento?
talvez o problema seja o BC encasquetar com o prazo de conclusão do recebimento (a média de tempo iria subir)
e eu não exemplifiquei antes, então deixa eu esclarecer:
+) normalmente pode ser substituído por um regex de maior especificidade e menos oneroso.
o exemplo dado ^(\d+)$ (que aceita txid vazio ou somente números) poderia ser simplesmente ^\d$
Se ele for notificado quando for desarmado, ele saberá que está OK até que o avisem do contrário
Aí é que tá. Vamos pensar mais um pouco, mas é algo que começa a ficar muito complexo, até para o integrador, ficará a dúvida:
- Será que minha regex tá ok?
Seria um forma mais enxuta de reescrever a primeira proposta <@!522899003663450113>! É uma boa.
No final a proposta do <@!440035527127990273> mantém a liberdade inicial e retira maiores problemas. Acho que resolve.
seria possível o tempo de execução ser medido também em produção? desarmaria o validador de txid se estourar o prazo de validação X vezes dentro de Y tempo
é interessante testar o tempo de avaliação contra algumas strings, mas ainda podem ter strings não previstas que sejam onerosas para um regex que já foi aceito
poderia testar o regex informado pelo cliente num crivo assim:
[\}\+\?\]\)\
se der match, recusa
vai barrar coisas como:
...{1,}) (que tem o mesmo efeito do exemplo abaixo)
...+)
...?)
o problema do exemplo é ter ) (especialmente mais pesado precedido de +, pois se torna uma iteração de testes dupla, ou um "loop encadeado")
