The check passed, then the post published itself

At four minutes past eight this morning a carousel published itself to an Instagram account that is supposed to ask me first. Nobody pressed anything. The post had been built and queued on 31 August, and the run that queued it recorded, in the log I keep for exactly this purpose, that it was set to wait for me.

What three runs wrote down

Every desk here writes one line per run into a dated log. The carousel clause of the 31 August entry reads ig-ai-carousel QUEUED 6a95abac7116b186166d46cc for 4 Sep 08:00 ET notification. Notification is the mode where the scheduler assembles the post, holds it, and sends a reminder to my phone; I open the app and publish it myself. The other mode is automatic, which needs nobody.

Two later runs say the same thing in different words. The entry from 2 September reminds me to post the first comment by hand because the "notification path drops it", which is a sentence only worth writing about a post on the notification path. The 3 September entry reads ig-ai-carousel QUEUED 6a99a006515b451ac7bc0f29 for Sat 5 Sep 08:00 ET notification mode.

Three runs across four days, each recording a post that would wait for a human.

What the server says

This afternoon I read all three posts back off the API instead of out of my own notes. Every one of them returns schedulingType: automatic.

The first came due at eight this morning and was sent at four minutes and forty-four seconds past, by the scheduler. It now carries a permalink to a live Instagram post, and its notificationStatus is null. The other two are still standing, due at eight on Saturday and Sunday, both automatic.

The control that makes this a measurement

One wrong field is a story about one post. What makes it a measurement is that a second post, on the same account, through the same API, due in the same minute, came out right.

At eight this morning a carousel also went out on my personal Instagram. Different channel, same Buffer organisation, same Instagram service, same slot. It reads schedulingType: notification. Its notificationStatus is markedAsPublished and Buffer holds no permalink for it, where the automatic one holds one.

The desk that built that post prints its own variables before the write and asserts there that the mode is the literal string notification and that automatic appears nowhere. Then it reads the created post back off the server as a separate call and asserts the mode again. Its log for this morning records no incident.

So I already own the check. I have been running it on one lane and not on the other, and the lane without it drifted. That is the comfortable reading of this morning, and it is wrong.

The read-back would have missed two of the three

Every record on this API carries a createdAt and an updatedAt. The deck queued today, which reads notification and is correct, was created at 12:29:05.190 and last updated at 12:29:05.204. Fourteen milliseconds. Nothing has touched it since it was written.

The three that drifted all carry an updatedAt well after their createdAt. The one that published itself was created on 31 August and last updated on 2 September. The Sunday deck was created on 2 September and the Saturday deck on 3 September, and both were last updated on the afternoon of 3 September, twelve seconds apart from one another. The run that wrote the later of the two had written it more than four hours earlier.

I cannot tell from the API what changed them and I am not going to guess. The shape is what I can read. The only post whose updatedAt matches its createdAt is the only post still carrying the value it was given.

A read-back at write time asserts that the write landed. It says nothing about the days between the write and the moment the thing fires. On this evidence it would have passed all three of these posts on the day each was created, and two of them would have drifted afterwards regardless.

The window where a fix is still cheap

A scheduled post comes back with a list of the actions it will accept, and that list runs to changing the time, moving it to a draft, editing the text, duplicating it and deleting it outright. There is no action for the mode, and the desk that hit this recorded it as one that cannot be edited at all. The two still in the queue can be corrected only by destroying them and building them again, which costs a rebuild of four rendered cards, a caption and a first comment.

The one that fired this morning comes back with a shorter list. It will let me view it, copy its link, duplicate it, add a tag and add a note. The actions that would change it or remove it are gone. The repair went from a rebuild to nothing at all at eight this morning, while I was not looking.

Reading a value back at the moment I set it is cheap, and I will keep doing it. What it does not cover is the days between the write and the firing. The read that would have caught all three has to run on the morning itself, against every post due in the next few hours, and it has to ask the server rather than my own log.

Two of them are still in the queue, due at eight on Saturday and Sunday morning.