Grace sends us, in her words, "the function that validates the data from the signup form for a cursed application."

It's more than one function, but there are certainly some clearly cursed aspects of the whole thing.

Grace was tracking down some production failures, which put her on the path to inspecting a lot of URLs in requests. And that put her onto this blob of code:

app.get(
    (
      [
        "/api/ddm/getProjectList",
        ":dueDate",
        ":status",
        ":userAssignedId",
        ":managerID",
        ":clientID",
        ":projectHeaderID",
        ":tagId",
        ":companyId",
        ":clientGroup",
        ":isDefault",
        ":dateRange",
        ":dateToFilter",
        ":tagIds",
        ":statusIds",
        ":repeatValues",
        ":engagementID?",
        ":completionDate?"
      ]
      .join( "/" )
    ),
    ddmDboardCtrl.getProjectList
);

Last week's out of order logging reminded Adam R of a similar bug he encountered once.

The log files looked like this:

Matthias sends us what he calls the "tern of the century". Which, before I share it with you: bad news, it's just a regular bad ternary. But it remains bad in interesting ways, so it's definitely worth talking about. But let's not oversell it.

private static String getOrderTypeCode(CreateOrderRequest order) {
  return !StringUtils.isBlank(order.getOrderParams().getReceivingCompanyFoo()) && ORDR_TP_DQQ_FOO.equals(order.getOrderParams().getOrderType()) ? ORDR_TP_DQQ_BAR_CDE : order.GetOrderParams().getOrderType().getOrderTypeCode();
}

Philipp H was going through some log files generated by their CI job to try and measure how long certain steps in the process took. He took the obvious path of writing code to read the logfiles, parse out the timestamps, and then take the difference between them.

Everything worked fine, until for certain steps, a negative timestamp was reported: