A Wrong Finding Got Written Down, And For Three Weeks It Was The Truth

Key takeaways

• On August 1 we wrote down that the call listing our blog posts was broken. It came back with an empty list and a success code, so the pipeline stopped trying to read post ids from it.
• On August 18 a later session read that note, believed it, and recorded the same conclusion again.
• On August 20 we found the call was fine. It wanted its status filter in capital letters. Lowercase, or no filter at all, returns an empty list with a 200.
• All 51 posts listed fine, and always had. Nothing about the tool changed. Only the note was wrong.
• The lesson for any business: a guess turns into a fact the moment somebody writes it in the file the next person reads first.

Every business has a sentence like this somewhere. "That supplier doesn't deliver here." "The old system can't export." "We tried that, it doesn't work." Somebody wrote it down once, it sounded sure, and nobody has tested it since. We run Go High Level in the Bay Area for ourselves and for clients, and this summer one of those sentences ran our own blog pipeline for three weeks.

The note that said the tool was broken

This blog is written by a daily pipeline. To do its job it needs to know what is already on the blog, which posts exist, what their ids are, which ones are still drafts. The platform has a call for exactly that: list the posts.

On August 1 that call came back empty. Not an error. A clean success code and a list with zero posts in it, on a blog that plainly had posts. So the pipeline's state file recorded the read path as unusable, and from then on the pipeline worked without it. It stopped capturing post ids from the list and worked around the gap.

That was a reasonable call on the day. An empty answer with a success code really does look like a broken endpoint. The problem is what happened next.

How a guess became a fact

On August 18 a different session picked up the pipeline. The first thing it read was the state file, and the state file said the list call does not work. So it did not try very hard. It confirmed the empty answer, agreed with the note, and wrote the same conclusion down a second time.

Now there were two entries saying the tool was broken. Anybody reading the file would assume it had been checked twice. It had really been guessed once and copied once.

That is the honest lesson for me. A wrong first read happens, and I can live with that one. What hurt was that once it sat in the file everybody reads first, nobody treated it as a guess anymore, and nobody retests something they think is already true.

What was actually going on

On August 20 we went back to the call and tried it every way we could think of. The answer was boring. The call wants a status filter, and it wants it in capital letters. Ask for published posts in capitals and you get every published post. Ask in lowercase, or leave the filter off, and you get an empty list with a success code. No warning, no hint that you asked wrong.

All 51 posts listed fine. They always had. Nothing about the platform changed between August 1 and August 20. The only thing that changed was that somebody stopped trusting the note.

Now the rule is written where the old note used to be: page through each status separately, published, draft, scheduled and archived, in capitals, and merge them. It is also in the instructions for the daily job itself, in plain words, so the next session reads the fix before it reads anything else.

The second trap that lives with it

Once the list call was working again, it showed us a second habit. Every so often, the exact same request, byte for byte, fails with a server side error, and a few minutes later succeeds again. Nothing on our end changes between the two.

If we had hit that first, we would have written the call off as broken all over again, and this time we would have had a real error message to point at. So the pipeline now does two things. It retries a failed list call instead of trusting one failure, and it keeps a snapshot of the last good listing on disk, so a bad minute on the platform does not leave the job blind.

What this means for Bay Area businesses running Go High Level

Your account is full of notes like ours, and most of them are not in a file. They live in a team member's head or in an old message thread. "That automation never worked." "The calendar can't do round robin for us." "Our form can't send to two people." Some are true. Some were true two platform updates ago. Some were never true and just came from somebody asking the question wrong once.

A few habits we would push on any Go High Level account in the Bay Area:

• When something "doesn't work," write down how it was tested, not just the verdict. A verdict with no method cannot be checked.
• Put a date next to every "can't." A limitation recorded in spring deserves a retest by fall.
• Treat an empty answer with no error as a question, not a result. A blank report is often a filter asked the wrong way.
• When a second person agrees with a note, ask whether they tested it or read it.

We lost three weeks to a sentence in our own file, and the fix took one afternoon. I would bet a few of the "can'ts" in your business would fold the same way if somebody retested them once.

Want to build this yourself?

Join the On Point Tech Academy at optechsol.llc/academy. It's free, and we build live every Tuesday and Thursday.