On 13 September 2026 I reconnected my X channel in the scheduling service I post through. I did it to fix one problem, and it fixed it. It also gave the channel a new id. From 08:48 that morning, my config pointed at a channel that no longer existed. Nothing raised an error. The status card kept showing the channel as healthy. That card only ever asked the service whether the stored id was valid. It never asked which id was current.
What I wanted was small. My X account had moved to Premium on 9 September. That lifts the post length from 280 characters to 25000. I wanted the agents that post for me to use that room. Underneath that, I wanted something I had never thought to ask for. A channel should stay the same channel after a reconnect. Clicking a button in someone else’s settings page should not cut off my plumbing.
I believed a channel id was stable as long as the account behind it stayed the same. Same X account, same handle, same login, so the same id. I believed the same about the length limit. I had upgraded, so the limit was 25000, and I wrote that number into the code. Both beliefs treated the id and the limit as facts about my account. Neither of them was.
The id belongs to the connection, not to the account. A reconnect creates a new connection, and the new connection gets a new id. The old one just drops out of the service’s channel list. Everything the service had stored about the old connection went with it, including what it knew about my subscription. That part matters. The service does not apply its length table to what the X account can do. It applies it to a field called subscriptionType, which it reads once, when the channel is connected. Mine had been read on 12 May 2026 and never refreshed. Its updatedAt was identical to its createdAt, and it said None. So between 9 September and the reconnect on 13 September, the service rejected every post over 280 characters. My code was sure the limit was 25000.
Der Reconnect tauscht die Kanal-ID — X zeigte seit 08:48 ins Leere
The reconnect swaps the channel ID — X had been pointing into nothing since 08:48
The first commit was a one-line fix: swap the dead id for the new one. Its message already named the bigger problem. Every channel I post through is pinned by id, and there are four of them with X included. A reconnect on any of them would take that channel offline in exactly the same way, with no error. Replacing one id fixed the spot where the problem showed up, not what caused it. Resolving channels by service and account name was left for a separate change.
Die X-Zeichengrenze wird aus Buffers Abo-Feld gezogen statt abgeschrieben
The X character limit is read from the scheduler’s subscription field instead of copied
The second commit went after the limit. The 25000 had been copied from the service’s documentation, and a second project had copied it from the first. A test held the two against each other and passed. It was comparing two copies of the same mistake. The service had answered long before. On 11 September at 05:15, card #489 had been rejected at 493 characters, with the message that posts cannot exceed 280 and nothing was transmitted.
- 2026-09-13I replaced the dead X channel id with the one the reconnect had created at 08:48. I also wrote down that every other channel is pinned the same way and would fail the same way.
- 2026-09-13I fetched the subscription field along with the channel list and derived the limit from it, with null meaning not measured. I set the static table to the smaller value and deployed both projects after running only one suite. The send route was left reading that table.
- 2026-09-13I moved the length check in the send route behind the channel lookup, so it reads the limit from the channel. I added a fixture that carries the subscription field, plus three test cases.
- 2026-09-13The night log recorded that #510, at 533 characters, was no longer blocked by length after a recheck at 11:05.
- 2026-09-13I wrote up the day. The limit had come from the docs, not from the other side, and had been wrong for four days.
Berichtigung zu 7f2f82e6: auch die Versandroute muss den Kanal fragen
Correction to 7f2f82e6: the send route has to ask the channel too
My fix had flipped the error. I had set the table’s X entry to the value without a subscription, so that anyone reading it directly would get the smaller number. I never checked who read it directly. The send route did, right at the top, before it looked up the channel. In the morning the code said 25000 and the service enforced 280, so #489 was rejected over there. By midday the code said 280 and #525 was rejected here, at 606 characters the service would have taken.
The order of the checks was the cause. The length check ran before the channel check. A check that runs before asking the channel cannot know the channel’s limit, so it has to make one up. Now it runs afterwards, and a subscription that hasn’t been measured blocks nothing. The tests now cover three cases: rejected at 280 without a subscription, the same text passing with one, and no judgement when the field is unmeasured. The middle case is the control. Without it, the first could pass even if the route rejected everything.
What I got wrong was simpler. For the first fix I ran only the second project’s suite, which was 4045 green, and then deployed both. The first project’s suite had a test for exactly this case: a long post inside the Premium limit goes through. That test went red as soon as it ran, but I hadn’t run it. If you change two repositories, you run two suites. After the correction, a mutation probe that forced a fixed 280 turned four tests red, and the suite ended at 959 green.
The record does not quote me naming a tool. A test file changed in the correction, so node –test was presumably involved. I’m inferring that from the file; I didn’t write it down. One side finding came from querying the service’s configuration directly. The comment limit on another network was 1248, and my code had 1250. For posts the service publishes no limit at all. That one can only be measured through a rejection.
It’s partly solved. The X limit now comes from the subscription field the channel reports, not from a copy of the docs. The send route asks the channel too, not just the check. The dead id is gone, and according to the day’s handover, a reconnect that swaps an id now gets healed instead of silently followed. A rejection with a number in it is now read as a measurement. The record does not show whether anything actually went out on X afterwards. The next step it lists was to measure exactly that the following morning. The rejection card for #489 was also still open, reporting a contradiction the reconnect had already resolved.
Three commits on 2026-09-13, plus two handover notes from the same day. All quotations are from the original commit subjects.
a821b3b6 · 7f2f82e6 · beb9e534
