Skip to content

App: repeater admin parsing still lets a TypeError through on odd server fields #517

Description

@MrAlders0n

A few places still trust the shape of what the server or the radio hands back:

  • RepeaterClaim.fromJson reads repeater, name and iata with as String?. A non-string value throws a TypeError, and tryFromJson only catches FormatException, so one odd row aborts the whole mine reconcile instead of being dropped. RepeaterAdminApi already has tolerant _asString / _asInt helpers for exactly this; the models should use the same idea.
  • ProvenNeighbour.tryFromJson has the same as String? on hex / prefix, and heard_at accepts an int or a numeric string but not a num, unlike snr two lines up.
  • RepeaterClaim.fromJson's FormatException message carries the full raw key, while hexToBytes next to it truncates to a prefix. Nothing logs it today, but a later debugError('$e') would leak a whole key.
  • parseNeighbourPage has no guard on prefixLen < 1, so a bad caller value ends in a RangeError rather than the FormatException everything else raises.
  • AccessList.entries and NeighbourPage.entries hand out growable lists; wrapping them in List.unmodifiable would stop a consumer mutating a parse result in place.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions