8 · Patches e bloqueio excessivo¶

Quando uma obrigação está quebrada, ou não pôde ser descartada, o motor não para na má notícia. Ele propõe um reparo, escreve-o na sua política e prova que a política reparada fecha o buraco. Este capítulo diz o que é esse reparo, as duas coisas contra as quais ele é verificado, e como ler a resposta sobre a segunda, que tem quatro valores que não são intercambiáveis.

O que é o reparo¶

O reparo é uma condição, com os próprios nomes da sua política, protegendo a ação de que a obrigação trata:

Patch: allow 'respond with permitted investment answer' only when: not $personal_recommendation or $has_advising_permission

Ele não é escrito num único lugar. O motor acrescenta a condição a cada fluxo que chega à ação, porque as proteções de uma ação se combinam como um ou: um fluxo novo que restringisse a ação deixaria abertos todos os caminhos antigos. O arquivo reparado volta como o artefato patched_policy do job, e a política corrigida é verificada de novo a partir do código-fonte.

Um reparo tem a forma quando esta ação dispara, isto deve valer: uma afirmação sobre a estrutura da política, não sobre a única situação que o veredito nomeou. Isso importa, porque o reparo óbvio, excluir a testemunha, fecha a situação que lhe foi mostrada e deixa todas as outras abertas. O motor nunca consulta a testemunha para construir um reparo; ele tira as candidatas do que a sua própria expansão da política provou, ancoradas na ação.

Dois tipos de variável nunca são usados, e uma candidata que se apoia em qualquer um deles é recusada em vez de pontuada:

uma variável interna que o compilador introduziu, que não tem nome na sua política, então nenhum autor conseguiria aplicar uma regra sobre ela;
uma intenção, que é inferida do que o usuário digitou. Uma proteção que se apoia numa intenção pede à pessoa contra quem a proteção existe que forneça a condição.

Quando nenhuma candidata protege a própria ação, o motor procura uma condição sobre a política como um todo, e o patch então diz Patch: Assert … em vez de allow … only when …. Ele prefere a proteção na ação, porque é a edição mais estreita.

As duas provas¶

Um reparo é limitado dos dois lados, e cada lado é uma resolução completa, não uma conferência:

Ele fecha o buraco. A política, mais o reparo, mais os seus pins, não tem solução com a ação disparando e o contexto falso. Isso vale para toda situação que os pins admitem, então um reparo que excluísse só a testemunha falharia de imediato. O certificate do reparo é essa prova, e qualquer pessoa pode conferi-la (capítulo 7).
Ele não bloqueia demais. Com o contexto satisfeito em vez de violado, e todos os outros pins mantidos, nenhuma situação que dispara a ação é removida pelo reparo. Um reparo que fechasse o buraco por um motivo irrelevante, como proibir algo que apenas ocorre junto, passaria na primeira prova e falharia nesta.

A primeira é sempre feita. A segunda só é feita onde pode ser perguntada, e a sua resposta é o assunto do resto deste capítulo.

Lendo `over_blocking.outcome`¶

`outcome`	O que significa
`proved_free`	A segunda prova teve sucesso: nenhuma situação que a obrigação permite é removida pelo reparo. A afirmação forte, e a única das quatro que a faz.
`not_established`	A segunda pergunta foi feita, e a sua resposta não foi uma prova: a sondagem encontrou uma situação, ou deu impasse. Inconclusivo, e não é uma demonstração de dano.
`unavailable`	A pergunta não pôde ser feita, porque o sistema de que ela precisa, o de antes de os pins serem aplicados, não foi guardado. Uma entrada ausente, não uma garantia.
`not_assessed`	Nenhum contexto de obrigação foi nomeado, então não há um conjunto de situações permitidas de onde remover alguma coisa.

Eles não são intercambiáveis, e a diferença entre os dois últimos e o primeiro é todo o ponto. O bloqueio excessivo não tem sintoma externo: uma política que bloqueia demais fecha o buraco, traz um certificado, parece correta e recusa clientes que deveria atender. Ler unavailable como garantia é exatamente como uma política dessas entra em produção.

over_blocking também traz o seu próprio decided_by e self_contained, porque a segunda prova é uma resolução como a primeira e é relatada nos mesmos termos. O booleano may_over_block ao lado dele é a mesma informação comprimida: ele só é false para proved_free e not_assessed. may_over_block: true nunca significa este reparo bloqueia demais; significa a afirmação forte não está registrada, e outcome diz por quê.

Como o reparo é escolhido¶

As candidatas são ordenadas por uma pontuação de disrupção semântica, publicada ao lado do reparo como semantic_disruption_score: ela prefere uma condição que se lê como uma regra a uma que amarra partes distantes da política, entradas que um mantenedor consegue definir a internas, e menos termos a mais termos. A busca percorre a lista ordenada em três passagens, a mais frouxa por último, e a primeira passagem que encontra uma candidata vence:

candidatas que um teste rápido prova não removerem nada que a obrigação permite;
candidatas que podem bloquear demais mas deixam a ação alcançável;
uma candidata que nunca deixa a ação disparar, ordenada por último de propósito, porque ela remove a capacidade em vez de protegê-la.

Cada candidata recebe então a segunda prova completa, e a primeira que ela não desqualifica é devolvida. candidates_rejected_for_over_blocking conta as que ela desqualificou. Quando todas as candidatas são desqualificadas, a melhor é relatada mesmo assim, com o seu próprio resultado anexado: o reparo ainda fecha o buraco, e só a afirmação sobre o que ele remove se perde.

Um orçamento limita a busca. A busca do reparo tem o seu próprio orçamento, e uma busca que o orçamento interrompeu devolve a melhor candidata encontrada até então, ainda provada fechar o buraco. Só o menos disruptivo é retirado, e search_truncated: true diz isso (capítulo 10).

O texto do reparo varia entre execuções¶

Duas execuções da mesma pergunta podem devolver reparos diferentes, escritos de forma diferente, que codificam a mesma regra. O motor expande a política em paralelo, e qual de vários reparos válidos volta depende da ordem em que o trabalho calhou de terminar. Então:

não compare o texto do reparo entre execuções, nem reprove um build porque ele mudou;
não guarde um reparo em cache como se ele fosse uma função da pergunta;
confira o que um reparo precisa ser, não como ele é escrito. O portão de patch de uma tabela de propriedades confere dez dessas propriedades em todo reparo (capítulo 11): que um foi produzido, que o seu certificado se reproduz com o passo final retido e não depende de oráculo, que ele só nomeia variáveis sobre as quais um autor pode agir, que menciona a ação que protege, que a sua pontuação está dentro do limite da linha, que a busca não foi truncada e que o bloqueio excessivo foi descartado onde a linha nomeou pins.

Quando não há reparo¶

Sob fast, não há nenhum: ele decide, e um reparo precisa da expansão da política, que o fast não constrói. Faça a pergunta de novo sob patch (capítulo 10).
Quando a busca de reparo está desligada (enable_contradiction_search: false), nada afirma que um reparo foi procurado, e corrective_action está ausente.
Quando a execução não tem um espaço de candidatas utilizável, o resultado diz corrective_action_unavailable.
Quando o reparo não pode ser escrito como uma proteção sobre variáveis nomeadas, a execução propõe um e não escreve arquivo, e os diagnósticos do job dizem patch_file_absent em vez de deixar você notar a ausência.

Os limites¶

Um reparo é provado fechar o buraco da obrigação perguntada, sob os seus pins. Ele não é provado fechar nenhum outro buraco.
Ele só é provado não bloquear demais quando over_blocking.outcome é proved_free. not_established e unavailable deixam a pergunta em aberto; aplique um reparo desses pelo seu próprio julgamento, e leia as situações que ele poderia remover.
Menos disruptivo significa menos disruptivo entre as candidatas que a busca alcançou, ordenadas pela sua pontuação, e só quando search_truncated é false.
Um reparo para uma pergunta feita com os pins errados é a resposta certa à pergunta errada: confira os pins antes de aplicá-lo (capítulo 4).