The abort guard that lied

2026-08-30 · automation · 5 min

We run an agent that submits proposals on a freelance marketplace through raw Chrome DevTools Protocol. Before it clicks the final send button, an abort guard reads the form back and refuses to submit unless every field checks out: the price, the deadline, the confirmation checkbox, and a minimum length on the message. The guard exists so that the agent can never fire blind.

This week the guard did its job perfectly — and it was wrong.

What happened

The target project sat behind a 24-hour exclusivity gate, so the script polled the page until the gate lifted, then filled the form. The log read:

poll 39: exclusivo=False botao_visivel=True
abrir form: True
pre-submit: {}
ABORTED: form incomplete — nothing sent

Every field had just been filled. The guard saw none of it.

The bug

The guard was written as an arrow function expression and passed to Runtime.evaluate:

pre = pg.ev("""()=>[document.querySelector('#oferta')?.value,
  document.querySelector('#confirmar-envio-proposta')?.checked, ...]""")

evaluate runs an expression. A bare arrow function is a perfectly valid expression — its value is a function object. Serialized with returnByValue, a function becomes {}. The guard didn't fail to run; it ran to completion and returned the function itself, un-invoked. One missing pair of parentheses.

pre = pg.ev("""(()=>[...])()""")   # invoke it

Fixed and re-run: pre-submit: ['900', '10', True, 1356] — guard green, send fired, the marketplace's own "cancel / improve proposal" controls confirmed the submission, and the panel now lists the proposal with the exact price and duration the guard verified.

Why this one matters

• The safe direction of a guard still lies. Aborting when nothing was wrong costs a real opportunity: the exclusivity gate had just opened, and a competitor's proposal sent during our false abort gets read first. Fail-safe is not the same as fail-correct.
• {} was honest output, not an error. No exception, no stack trace — the code returned the truthful serialization of a function object. Bugs that produce silence-shaped data are the ones that pass review.
• Verify the verifier. The right test for a guard is to run it against a known-good state and assert it says yes. We had only ever tested the refusal path (empty form → abort). The approval path had never fired a true positive before it needed to.

The rule we took

Any guard whose expression is handed to an evaluator gets its result asserted against a positive control once, in a dry run, before it is trusted to gate a real action. If your verification step has never returned "go" on a state you knew was good, you don't have a guard — you have a coin that only ever lands on "no".