Sure, this addresses my concerns. Personally, I'd drop the recommendation of synthesizing rollback, since it's error-prone especially for some providers, but I'm also not particularly bothered. Thanks a ton for addressing this, I appreciate it.

I will make the language a little more cautious about rollback then.

One last thought... should it be called AtomicError? can't decide between the "Err" pattern I've seen in Go std lib, or just spelling things out because it's not like it's a frequently used identifier.

One last thought... should it be called AtomicError? can't decide between the "Err" pattern I've seen in Go std lib, or just spelling things out because it's not like it's a frequently used identifier.

I think that AtomicErr is probably better since it matches the stdlib, but AtomicError seems fine to me too.

Sounds good, thanks both!

Is this pattern production ready?

I upgraded my libdns ovh package with SetRecords atomatic behavior, I used the AtomicErr type.
I used the head commit in my go.mod, until a tagged version is ready.

@gjung56

Is this pattern production ready?

I upgraded my libdns ovh package with SetRecords atomatic behavior, I used the AtomicErr type. I used the head commit in my go.mod, until a tagged version is ready.

Ok, I've tagged v1.1.0 just now, so you should be able to use that instead. Hopefully @mholt doesn't mind :)

Not at all, thank you for beating me to it!