[TomOnTime]

Problem

Integration tests on LUADNS occasionally fail with a 500:

± MODIFY ***-luadns.com HTTPS (3 example.com. alpn="h2,h3" port="999" ech="some+base64+encoded+value///" ttl=300) -> (3 example.com. alpn="h2" port="80" ech="some+base64+encoded+value///" ttl=300)
Server returned bad status code (500)

Cause

The payload appears valid: reproducing test 19 locally produces 3 example.com. alpn=h2 port=80 ech=some+base64+encoded+value///, which has the same shape as test 18's PATCH that succeeds with the same ECH value. Since the content we send is deterministic and the failure is intermittent, this looks like a transient server-side error. (luadns-go discards the 500 response body, so the server's reason isn't visible.)

Fix

New providers/luadns/retry.go, following the policy in providers/mittwald/retry.go:

• 429: every request is retried (it wasn't processed).
• 500/502/503/504: requests that can't create anything twice (updates, deletes, reads) are retried with a doubling pause (2s, 4s, …, capped at 30s; up to 6 retries).
• Creates (POST: records and zones): not retried after a 5xx, since the first attempt may have succeeded and a retry could duplicate it.

All LuaDNS API calls now go through the helper, which also does the rate-limiter wait.

Testing

• New retry_test.go covers the retry/no-retry cases.
• go test ./providers/luadns passes; go build ./... passes.
• Not yet re-run against the live LuaDNS integration tests.

🤖 Generated with Claude Code

[TomOnTime]

@riku22

The integration tests were failing occasionally. I asked Claude to take a look, and it concluded the 500s were LUA's fault, not ours. It suggested retrying 500s and wrote this solution, which seems rather large for a small problem.

I asked it to create a smaller solution. It created #5042 which isn't as clean but doesn't rewrite the entire retry mechanism.

I'm ok with either solution. As the maintainer, do you have a preference?

[riku22]

Thank you.

Since there are few corrections needed, #5042 seems like a better choice.