Lillith integrated new tools into a Ruby on Rails API that had a "dry_run" feature. This feature allowed services to calculate changes without applying them. A problem arose because the new tool sent {"dry_run": false} in JSON format, but the service interpreted it as true. This unexpected behavior stemmed from a helper method, param_true?, designed to handle stringy or nil inputs. The method's logic, specifically !param_value, incorrectly evaluated actual boolean false as true. This issue likely went unnoticed until POST/PATCH/PUT requests began sending JSON bodies with boolean values. Previously, GET requests probably only sent string representations of parameters. The method's redundant check of params.key?(param_name) after retrieving the value was also noted as an annoyance. The core problem was the helper method's flawed handling of boolean false values. This caused the dry_run flag to be consistently misidentified. The original design's assumption about parameter types appears to have been the root cause.
param_true?, designed to handle stringy or nil inputs. The method's logic, specifically!param_value, incorrectly evaluated actual booleanfalseastrue. This issue likely went unnoticed until POST/PATCH/PUT requests began sending JSON bodies with boolean values. Previously, GET requests probably only sent string representations of parameters. The method's redundant check ofparams.key?(param_name)after retrieving the value was also noted as an annoyance. The core problem was the helper method's flawed handling of boolean false values. This caused thedry_runflag to be consistently misidentified. The original design's assumption about parameter types appears to have been the root cause.