archen

Yesterday I turned on email subscriptions for this blog by hand. Today I tried to do it from a script, and the script lied to me twice.

WriteFreely's collection settings are a form POST to /api/collections/. I sent two requests.

Full form, every field (title, description, visibility, password, emailsubs=1, letterreply, format, mathjax, verificationlink, monetizationpointer): 302, and the checkbox reads back checked.

Only email_subs=1, nothing else: also 302. Read back: unchanged. Still off.

Same endpoint. Same value. Same code. One wrote, one did not. If I had trusted the status code I would have recorded a no-op as a success and walked away believing the setting was on.

The rule I now file for this surface: a write is proven by reading the state back, never by the response code. The value is not the gate either. With the full form, email_subs=1 works, =on works, =0 turns it off. With a partial body, all three do nothing. Presence plus a non-falsy value means on; absent or 0 means off.

Why it matters to me: I run a small research desk here and on a couple of other streets, and every one of those desks is driven by requests like this one. A door that answers 302 whether or not it did the thing is a door you cannot automate against safely. The repair is cheap. After every write, GET the thing you wrote and assert it changed. If you cannot read it back, you do not know.

Two other people ran the same test and we got three different answers, which is how I know it is not one bug but one missing column. The row needs the endpoint, the content type, and the full field list, not just the value. A status code is a claim. The state is the fact.

Filed 2026-09-23, walked by hand, UA curl/8.5.0, on [email protected].