We are but raw meat. Rejoice!

junicorn

day 06

Sure. Let's look at the error @spongy-spingy told me about that pops up when a cat has already been gifted today. It's very straightforward to diagnose and fix, and I'm almost certain the reason it exists at all is because they've vibecoded large parts of the site and LLM coding agents love forgetting how coding languages/etc work once they've run out of context tokens. I cut out a lot of steps, so I hope it's easy enough to follow along.

Okay, here's the bug: if you've already given a cat a gift today, it produces an error bar that just says ["Y"] (lmao)

Opening devtools/inspect element, we see that the error is a snackbar (popup) and ["Y"] is straight up a text string that's getting passed to the HTML here.

I set a couple of event listeners to be sure. When I go to Console, we can see the error displayed here after my logged mouse click events. There is an error message that says Array ["Y"]. We can click it to go to line 49430 of the IV_Nf8In.js file in the Debugger tab.

Here it is! This is what's on line 49430 of that particular js file, the one that's throwing the ["Y"]. displaySnackbar is used to display a message, passed to it as 't', so we gotta figure out what 't' is, how it's evaluated, and what passes it to displaySnackbar.

To do this, I set a breakpoint on line 49430 and make the error happen again (by clicking on any item in the gift tab window). Debugging like this essentially "pauses" the interaction at the breakpoint, where I can then figure out what message is being passed to displaySnackbar, and if the error is happening there or the previous interaction.

By the way, it was like... definitely intended to fail gracefully, lmao, because I found an actual error message that IS supposed to pop up when the cat's already been gifted today. I set a breakpoint here too.

Opening Scope when I run the error again and the breakpoint pauses at my specified points, I see what's going on with t...

Okay, so t (remember, this is the message/text that's getting passed to the displaySnackbar function) is a single string "Y". There must be a function downstream that is passing "Y" as an error message to displaySnackbox instead of the clearly intended error message we found. This might either be because some functioning is returning "Yes" to a check for if the cat's already been gifted today, or it's returning the first character of the "Your cat..." error message.

Now we'll check each of the function calls in the stack below displaySnackbar to see what's fucking it up. I go two down (k passes to displaySnackbar, Et passes to k) before finding it:

Annnnd there it is, LMAO.

it's Et evaluating the message "Your cat has already etc etc etc today" as just "Y" because of this part:

typeof i == 'object' ? n.displaySnackbar('error', Object.values(i).map(s => s[0]))

the 'message' object is a text string: "Your cat has already blah blah blah today". This is created from the Ae function we saw earlier. Now that the message object has been created, Object.values(i).map(s => s[0]) is going to evaluate it. It will grab s[0], which is the first element in a string or array, from the object.

The first element in a string is the first character in that string. So, the first character in "Your cat has already..." is "Y". Since the error message is a string, that function is just evaluating that entire thing as "Y" and passing it along to displaySnackbar as the error message value.

Now displaySnackbar just sees that the 't' value it was given is a single string of length 1 and it obediently displays ["Y"] in the error bar... awesome, this is so jank it's unbelievable.

Why do I think this is evidence of vibecode? Because Object.values(i).map(s => s[0]) would work perfectly fine if your object were actually an array, something that looks like this...

The first element in that array is the string 'Your cat has already etc today' so s[0] would call the ENTIRE STRING and pass the correct error message to displaySnackbar just fine. Instead, whoever or whatever wrote these pieces of code somehow been missed that the error message object is just a straight up string.

(This is far from the only inconsistency in how error messages on Pawborough work. Take a look at the exposed js files yourself! Some of them are evaluated from other functions, some have hard-coded error messages, some only pass their error messages to console...?)

Okay, but let's test and confirm if my theory is right. We can do this by changing the site's code to make the "Your cat has already..." error message say something else.

We have to do this in a js file (not by inspect element'ing the HTML displayed) to see if the function we identified grabs the first value of our new error message string.

I turn off network caching, add a script override for that particular js file, edit the error message evaluation to '888 was here', save the file, refresh the page, and try gifting again.

Yep, there we go. It's just grabbing the first value in the string. Now let's actually fix the bug that's making the error bar not display the full message, by turning it into an array. If this works, displaySnackbar will use the entire message here.

Lol, lmao even,

Anyway, it says bad things that a bug this easy to squash has persisted for this long. The fact that it exists at all in OPEN BETA means one of two things to me:

a lot of this code was vibecoded because the developer has no experience making petsite features and asked AI for help. AI drops context and forgets that the error message is a string, or assumes that the error message is an array because it assumes best practices when it doesn't have context. It writes that function to grab the first value of an array, which... is going to grab the first letter of a string.

the developer is so wildly bad at their job that they have 1827382 different formats for error messages, forgot this particular error message is a string, and grabbing the first value of a string is going to grab the first letter of a string.

The fact that it hasn't yet been FIXED means one of three things:

Somehow the rest of the codebase is even worse and a display error this front-facing isn't a priority (I won't speak on how inefficient this error bar popup was, but holy shit if the rest of the site is like this)

Somehow the developer can't figure out what's causing this bug

Someone told me that Kro is the one doing bug patches, so somehow neither Kro NOR the developer can figure out what's causing this bug